Methode 2 wird eingesetzt, um die WrapperStartStopApp-Helper-Klasse zu nutzen.
Diese Methode liefert eine Möglichkeit für die Integration mit Anwendungen, wie z. B. mit Tomcat,
die durch Nutzen einer Klasse gestartet und durch Nutzen einer anderen Klasse beendet werden.
Diese Art von Anwendung öffnet beim Starten ein Server-Socket, dessen Aufgabe es ist, auf eine Verbindung zu warten, die ein Herunterfahren auslöst.
Das Herunterfahren oder die stop-Klasse
löst, wenn gestartet, das Herunterfahren durch das Verbinden mit der Anwendung aus.
Der Wrapper arbeitet mit dieser Art von Anwendung, indem er diese, wie in Methode 1, durch Nutzen der
start-Klasse startet und dann die Main-Methode der
stop-Klasse aufruft, wenn es Zeit ist, die Anwendung herunterzufahren.
Beim Integrieren mit Methode 2 ersetzt die WrapperStartStopApp-Helper-Klasse die Main-Klasse der Anwendung.
Dies gibt der WrapperStartStopApp-Klasse eine Chance,
den WrapperManager sofort zu initialisieren und die JVM mit dem Wrapper zu integrieren.
Die WrapperStartStopApp-Klasse verwaltet dann die komplette Interaktion mit dem Wrapper sowie auch den Lebenszyklus der Anwendung.
Wenn der Wrapper via WrapperManager eine Startnachricht an die JVM sendet,
wird die Main-Methode der start-Klasse der Anwendung aufgerufen.
Analog wird die Main-Methode der stop-Klasse der Anwendung aufgerufen, wenn der Wrapper eine Stop-Nachricht an die JVM sendet.
Wenn die WrapperStartStopApp-Helper-Klasse gestartet wird, muss sie über die
Klassennamen von sowohl der start als auch der stop-
Klasse informiert werden, ebenso wie über jegliche Parameter, die den Main-Methoden jeder Klasse übergeben werden müssen.
Dies führt dazu, dass die Parameterliste
etwas komplizierter ist, als die der Methode 1 (WrapperSimpleApp)-Helper-Klasse.
Der erste Parameter, der der WrapperStartStopApp-Klasse
übergeben wird, ist der vollständige Klassennamen der start-Klasse.
Dem folgt eine Anzahl von Parametern für die Main-Methode der start-Klasse, die darauf folgt.
Nach den Parametern der start-Klasse, folgt der vollständige Name der stop-Klasse.
Dem folgt ein TRUE/FALSE-Flag, die die WrapperStartStopApp class
darüber informiert, ob diese warten soll bis alle Non-Daemon-Threads beendet sind, bevor diese sich selbst beendet.
Diese Flag wird dann von dem stop-Klassenparameter Zähler und Parameter gefolgt.
Lassen Sie sich nicht davon aus der Ruhe bringen, wenn dies aktuell etwas verwirrend klingt.
Weiter unten finden Sie ein detailliertes Beispiel.
Detaillierte Anweisungen
Dieser Abschnitt führt Sie durch eine detaillierte Anleitung dafür,
wie Tomcat
innerhalb des Wrappers ausgeführt werden kann.
Die meisten anderen Anwendungen können durch dieselben Schritte integriert werden.
Tomcat installieren
Dieses Tutorial startet mit einer Neuinstallation von Tomcat.
Wir nutzen die Version Tomcat 9.0.0.M13, daher kann es sein, dass die Schritte bei sich leicht unterscheiden, jenachdem, welche Version Sie installieren.
Tomcat wurde in dem Root-Verzeichnis D:\ installiert,
Tomcat hat daher das Home-Verzeichnis D:\apache-tomcat-9.0.0.M13.
Wrapper-Dateien installieren
Es gibt vier Verzeichnisse, die konfiguriert werden müssen, damit der Wrapper verwendet werden kann.
bin-Verzeichnis
Zuerst kopieren Sie die folgenden Dateien in das bin-Verzeichnis von Tomcat:
Benennen Sie die drei Batchdateien um, damit Ihr Anwendungsname wie folgt wiedergegeben wird.
Stellen Sie bitte sicher, dass Sie die .in-Dateiendungen entfernen, so dass alle Dateien auf .bat enden.
(Abhängig davon, wie Ihr Dateiexplorer auf Ihrem Computer konfiguriert ist, kann es vorkommen, dass Sie Dateiendungen nicht sehen können.)
Die wrapper.exe-Datei ist die eigentliche Wrapper-Programmdatei.
Die drei Batchdateien werden genutzt, um Tomcat in einer Konsole auszuführen, und es als einen Windows-Dienst zu installieren/deinstallieren.
Diese Batchdateien sollten keine Änderung benötigen.
Sie folgen der Annahme, dass sich die wrapper.conf-Datei innerhalb
eines conf-Verzeichnisses befindet (eine Ebene höher, ../conf/wrapper.conf).
Wenn Sie die wrapper.conf-Datei woanders speichern möchten,
müssen die drei Batchdateien entsprechend geändert werden.
lib-Verzeichnis
Kopieren Sie die folgenden zwei Dateien in das lib-Verzeichnis von Tomcat:
Die wrapper.dll-Datei ist eine native Bibliotheksdatei,
die von dem Teil des Wrappers benötigt wird, welcher innerhalb der JVM läuft.
Die wrapper.jar-Datei enthält alle Wrapper-Klassen.
conf-Verzeichnis
Der Wrapper benötigt für jede Anwendung eine Konfigurationsdatei wrapper.conf.
Das Standardverzeichnis für diese Datei ist ein conf-Verzeichnis im Home-Verzeichnis der Anwendung.
Kopieren Sie die folgende Vorlagendatei wrapper.conf.in in das conf-Verzeichnis von Tomcat.
{WRAPPER_HOME}\src\conf\wrapper.conf.in
Benennen Sie die Datei wie folgt um.
Stellen Sie sicher, dass Sie die .in-Dateiendung entfernen, so dass die Datei wrapper.conf heißt.
Sie sollten nun Folgendes haben:
{TOMCAT_HOME}\conf\wrapper.conf
Wenn Sie die Konfigurationsdatei wrapper.conf an einen anderen Ort verschieben möchten, können Sie das tun.
Sie müssen die in das oben genannte bin-Verzeichnis kopierten Batchdateien ändern, so dass der neue Speicherort korrekt wiedergegeben wird.
logs-Verzeichnis
Die Standard-Konfigurationsdatei wrapper.conf legt eine
wrapper.log-Datei in einem logs-Verzeichnis unterhalb des Home-Verzeichnis der Anwendung ab.
Tomcat hat dieses Verzeichnis bereits, es kann also einfach weitergehen.
{TOMCAT_HOME}/logs
Wenn Sie die wrapper.log-Datei an einem anderen Ort speichern möchten,
müssen Sie die wrapper.conf-Datei
editieren und die wrapper.logfile-Eigenschaft ändern, damit der neue Speicherort wiedergegeben wird.
Festlegen der Java-Befehlszeile der Anwendung
Bevor der Wrapper dafür konfiguriert werden kann, eine Anwendung zu starten,
müssen Sie den kompletten Java-Befehl kennen, der normalerweise benutzt wird.
Die meisten Anwendungen verwenden eine Batch-Datei, um die tatsächliche Befehlszeile zu erstellen.
Diese Batchdateien neigen dazu, recht unhandlich zu werden,
daher ist die Möglichkeit, nicht mit ihnen zu arbeiten,
einer der Vorteile der Verwendung des Wrappers.
Tomcat wird standardmäßig durch Nutzung der Batchdatei startup.bat gestartet
und durch Nutzung der Batchdatei shutdown.bat beendet.
Es wird gestartet, indem man zuerst das aktuelle Verzeichnis auf das
bin-Verzeichnis ändert und es dann von dort ausführt.
Wenn Sie startup.bat in einem Editor öffnen, erden Sie nach kurzem Prüfen feststellen,
dass Java tatsächlich nicht von dieser Batchdatei aus gestartet wird.
Stattdessen wird eine andere Batchdatei, catalina.bat, aufgerufen.
Tomcat-Skripte sind sehr fortschrittlich und erlauben es dem Nutzer
viele Konfigurationen von der Befehlszeile aus vorzunehmen.
Die Befehlszeile, die wir mit dem Wrapper erfassen und nutzen, ist tatsächlich eine Momentaufnahme solch einer Konfiguration.
Dieses Beispiel nimmt an, dass keine Parameter während des Ablaufs der Start- oder Beenden-Skripte übergeben werden.
Wenn Sie catalina.bat in einem Editor öffnen und ans Dateiende scrollen,
werden Sie vier Zeilen sehen, die Java starten.
Mit den Standardeinstellungen, die wir verwenden, wird die erste davon genutzt.
Die Zeile, die uns interessiert, sieht wie folgt aus: (Der Befehl ist sehr lang und wurde verkürzt.)
Der Großteil des Skripts hat die Aufgabe, systemspezifische Informationen zu sammeln
und diese Information in Umgebungsvariablen zu speichern.
Die oben genannte Zeile expandiert dann alle gesammelten Informationen
in den schlussendlichen Java-Befehl, der die Anwendung startet.
Wir hoffen, dass Sie beim Betrachten des Quellcodes der Batchdatei
deren Komplexität erkennen und wieso wir Ihnen abnehmen möchten,
solche komplexen Skripte vollständig selbst zu schreiben.
Alles, was Sie zum Konfigurieren des Wrappers wirklich benötigen, ist die letzte, erweiterte Befehlszeile.
Anstatt das gesamte Skript zu lesen und zu versuchen, es zu verstehen,
werden wir einen einfachen Trick nutzen, um die letzte Befehlszeile in der Konsole anzuzeigen.
Bitte editieren Sie die Batchdatei catalina.bat indem Sie ECHO an den Anfang der oben genannten Zeile einfügen.
Wenn Sie das getan haben, sollten Sie Folgendes sehen:(Die Zeile wurde wieder verkürzt, damit sie auf den Bildschirm passt.)
Wir müssen nun die gleiche Vorgehensweise für die Batchdatei shutdown.bat
sowie die startup.bat oben wiederholen.
Sie werden erstaunt sein, festzustellen, dass wenn Sie diese jetzt ausführen, Sie das folgende Ergebnis erhalten würden.
Das kommt daher, dass sowohl startup.bat als auch shutdown.batcatalina.bat aufrufen und nur einen Parameter ändern.
Anders als start Tomcat am Anfang der Startzeile, sind die beiden Befehle beinahe identisch.
Der einzige Unterschied ist der Parameter, der am Ende an die Main-Klasse weitergegeben wird.
Der start Tomcat-Abschnitt des Befehls wird nur genutzt, um Tomcat in seiner eigenen Konsole zu erzeugen.
Dies ist bei der Nutzung des Wrappers nicht notwendig, daher wird der Rest dieses Beispiels diesen Abschnitt des Befehls ignorieren.
Der Wrapper kann auch mit Elementen der Java-Befehlszeile umgehen, die er aufbaut, die in Anführungszeichen stehen.
Es ist also nicht notwendig, diese in die unten angegebene Konfigurationsdatei wrapper.conf zu übertragen.
Ändern der "wrapper.conf"-Datei
Um die obengenannte Java-Befehlszeile mit dem Wrapper nutzen zu können,
müssen wir die Komponenten der Befehlszeile in eine Konfigurationsdatei aufteilen.
Öffnen Sie hierfür die wrapper.conf-
Datei in einem Editor und nehmen Sie die unten stehenden Änderungen vor.
NOTE
Wir haben ein paar Links bereitgestellt, in denen Sie die Beschreibung der genannten Eigenschaften finden.
Nehmen Sie sich bitte die Zeit, die Beschreibungen von jeglichen Eigenschaften anzuschauen, die verändert wurden.
In vielen Fällen gibt es vollständige Beschreibungen bezüglich ihres Einsatzes, die hier nicht aufgeführt werden.
Java-Programmdatei
Zuerst wird die Java-Programmdatei extrahiert und der Verzeichnispfad der
wrapper.java.command-Eigenschaft zugewiesen.
wrapper.java.command=D:\jdk1.8.0_45\bin\java
Java-Argumente
Die meisten Anwendungen liefern der Java-Programmdatei eine Reihe von Parametern, wenn diese gestartet wird.
Der Wrapper liefert besondere Konfigurationseigenschaften für Dinge wie Speicher sowie Klassen- und Verzeichnis-Pfade.
Diese werden weiter unten behandelt. Jedoch werden alle anderen Einstellungen durch den Einsatz der
wrapper.java.additional.<n>-Folge an Eigenschaften konfiguriert.
Die Tomcat-Befehlszeile hat mehrere solcher Eigenschaften:
wrapper.java.additional.1=-Dcatalina.base=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=D:\apache-tomcat-9.0.0.M13\temp
wrapper.java.additional.4=-Djdk.tls.ephemeralDHKeySize=2048
wrapper.java.additional.5=-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
# Following properties are optional:
wrapper.java.additional.6=-Djava.util.logging.config.file=D:\apache-tomcat-9.0.0.M13\conf\logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Bitte beachten Sie, dass alle Anführungszeichen entfernt wurden, da keiner dieser Pfade jemals Anführungszeichen enthalten wird.
Informationen darüber, wie man mit Eigenschaften, die Leerzeichen enthalten, umgeht, finden Sie in der Eigenschaften-Dokumentation.
wrapper.jar
Der Wrapper erstellt die Anforderung, dass die wrapper.jar spezifiziert wird:
The wrapper.jarfile property was introduced in version 3.5.55.
When using earlier Wrapper versions, it is necessary to include wrapper.jar in the classpath:
Then, the indices of next classpath elements must be adjusted so that the wrapper.java.classpath.1 property is not repeated.
Classpath
Als Nächstes kommt der Classpath, der unter Einsatz der
wrapper.java.classpath.<n>-Eigenschaft konfiguriert wird.
Der Wrapper erfordert, dass der Classpath in seine individuellen Teile aufgeteilt wird.
Die nächste Befehlskomponente, die genutzt wird, um Tomcat zu starten, ist die Main-Klasse org.apache.catalina.startup.Bootstrap.
Die von Java beim Starten ausgeführte Main-Klasse wird durch Nutzung der
wrapper.java.mainclass-Eigenschaft spezifiziert.
Da wir, wie oben erwähnt, die WrapperStartStopApp-
Helper-Klasse verwenden, um Tomcat zu starten und zu beenden, werden wir den vollständigen Namen dieser Klasse als Main-Klasse spezifizieren.
Die Tomcat-Main-Klassen sind dann wie die unten genannten Anwendungsparameter spezifiziert.
Die vollständigen Informationen zur Konfiguration dieser Eigenschaften finden Sie auf der Eigenschaften-Seite:
wrapper.app.parameter.<n>.
Anwendungsparameter erscheinen in der Java-Befehlszeile direkt hinter der Main-Klasse.
Wenn wir die WrapperStartStopApp-Helper-Klasse benutzen, müssen viele Informationen bereitgestellt werden,
sowohl über die start- als auch die stop-Klasse.
Diese Informationen beinhalten den vollständigen Namen, die Parameterliste, die den Main-Methoden übergeben werden und ein Flag, welches
der Helper-Klasse mitteilt, ob sie warten soll, bis alle Non-Daemon-Threads beendet sind, bevor sie die JVM veranlasst, sich zu beenden.
Wir erklären im Folgenden, wie diese Information programmiertechnisch umgesetzt wird.
Wir beginnen mit dem Anzeigen der Eigenschaftswerte für die Tomcat-Anwendung.
Oben wurden bereits mehrere Kommentare darüber hinzugefügt, was Sie normalerweise
in der wrapper.conf-Datei finden können.
Die Bedeutung jeder Eigenschaft wird einfach zu verstehen sein.
Wir schlagen vor, diese Kommentare auch Ihrer Konfigurationsdatei wrapper.conf hinzuzufügen.
# The first application parameter is the name of the class whose main
# method is to be called when the application is launched. The class
# name is followed by the number of parameters to be passed to its main
# method. Then comes the actual parameters.
wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
# The start parameters are followed by the name of the class whose main
# method is to be called to stop the application. The stop class name
# is followed by a flag that controls whether or not the Wrapper should
# wait for all non daemon threads to complete before exiting the JVM.
# The flag is followed by the number of parameters to be passed to the
# stop class's main method. Finally comes the actual parameters.
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop
Die start- und stop-Klassennamen sollten jetzt klar sein.
Der erste Parameter Zahl (count) wird benötigt, um die stop-Klasse in der Parameterliste zu finden.
Die zweite Zahl exisitiert für die Konsistenz.
Das Flag oben an Parameterstelle #5 wird genutzt, um das Verhalten der
WrapperStartStopApp-Helper-Klasse zu steuern, wenn sie die JVM beendet.
Wenn der Wrapper eine Beenden-Anforderung an die JVM sendet, antwortet, WrapperStartStopApp
durch Aufruf der Main-Methode der stop-Klasse mit den konfigurierten Parametern.
Das Flag oben kontrolliert, was passiert, wenn diese Main-Methode einen Rückgabewert liefert.
Wenn das Flag FALSE ausgibt, wird System.exit(0) sofort aufgerufen.
Wenn es TRUE ausgibt, wird WrapperStartStopApp warten, bis alle Non-Daemon-
Threads abgeschlossen sind, bevor System.exit(0) aufgerufen wird.
Letzteres ist das Verhalten, welches das beste Beenden für Tomcat ermöglicht.
Wenn TRUE spezifiziert wird, aber mindestens ein Daemon-Thread noch nicht abgeschlossen ist, wird der Wrapper
das Beenden der JVM erzwingen, nachdem das Time-out des Beendens abgelaufen ist.
Das Time-out ist standardmäßig auf 30 Sekunden eingestellt.
Non-Daemon-Threads werden gezählt, indem sie über alle Threads im System iteriert werden
und die gezählt werden, deren isDaemon-Methode FALSE zurückgibt.
Leider wird diese Zählung in den meisten JVM niemals wirklich "0" (Null) erreichen,
da die Systemthreads existieren.
In den meisten Oracle HotSpot JVMs gibt es einen Systemthread, der kein Daemon ist.
Damit das Beenden korrekt funktioniert, muss diese Systemthreadzahl auch korrekt sein.
Sie kann duch Definieren einer Systemeigenschaft festgelegt werden:
org.tanukisoftware.wrapper.WrapperStartStopApp.systemThreadCount.
Der Standardwert ist 1 Thread.
NOTE
Wenn die Main-Methode der stop-Klasse System.exit von innerhalb
seines Hauptthreads aufruft, wird dieser Thread tatsächlich durch diesen Aufruf geblockt.
Der Wrapper vermeidet einen Deadlock, indem er diesen entdeckt und mit dem Beenden nach 5 Sekunden fortfährt.
Dies kann jedoch in der Anwendung dazu führen, dass es der Anwendung misslingt, sich selbst korrekt zu beenden und sollte wo möglich vermieden werden.
Dieser Fall kann getestet werden, um die Eigenschaft wrapper.debug=TRUE zu aktivieren
und dann die Logdatei während des Beenden-Prozesses zu beobachten.
Bibliothekspfad
Um den Wrapper einzusetzen, gibt es eine weitere Eigenschaft, die gesetzt werden muss.
Der Wrapper benutzt eine native Bibliothek, um den Austausch mit dem System zu steuern.
Diese Bibliotheksdateiwrapper.dll
muss im Bibliothekspfad bestimmt werden, der gegenüber der JVM angegeben wird.
Tomcat hat keine eigenen nativen Bibliotheken, aber wenn es diese hätte,
müssten die Verzeichnisse, in denen sie sich befinden, auch spezifiziert werden.
Bitte beachten Sie, dass diese Konfigurationen auf diesem bestimmten Gerät korrekt zwar funktionieren,
diese aber sehr stark von der Verzeichnisstruktur und Plattform abhängen können.
Durch Nutzen der Tatsache, dass der Wrapper das Arbeitsverzeichnis
stets auf den Speicherort der wrapper.exe-Datei festlegt und durch Nutzen einer einzelnen Umgebungsvariablen sind wir in der Lage die oben genannten Eigenschaften zu ändern.
Dadurch sind sie vollständig plattform- und maschinenunabhängig.
Es wurde berichtet, dass Tomcat 5.0.28 nicht korrekt funktionieren wird, wenn das bin-Verzeichnis
in der java.endorsed.dirs-Systemeigenschaft enthalten wäre.
Dies hat seine Ursache vielmehr in einer Änderung von Tomcat, als dass es ein Problem mit dem Wrapper ist.
Bitte ändern Sie die oben genannte Konfiguration wie folgt:
Der abschließende Schritt ist es, die Windows-Diensteigenschaften festzulegen.
Wir werden nur die Eigenschaften festlegen, die geändert werden sollen, es sind jedoch weitere verfügbar.
Sehen Sie bitte in die Dokumentation zu Details bezüglich ihrer Verwendung.
Vorgeschlagene Werte für diese Variablen werden unten angezeigt.
wrapper.ntservice.name=Tomcat
wrapper.ntservice.displayname=Tomcat Application Server
wrapper.ntservice.description=Tomcat Application Server
Testen
Tomcat kann nun einfach durch das Ausführen der Batch-Datei bin\Tomcat.bat ausgeführt werden.
Aufgrund der Art, wie der Wrapper sein aktuelles Verzeichnis festlegt, ist es nicht notwendig, die Batch-Datei
von innerhalb des bin-Verzeichnisses auszuführen.
Bitte versuchen Sie, die Anwendung einmal als Konsolenanwendung auszuführen,
um die Konfiguration zu überprüfen, bevor Sie versuchen, diese als Dienst auszuführen.
Herzlichen Glückwunsch! Ihre Anwendung sollte jetzt laufen.
Wenn Sie Probleme haben, finden Sie im Abschnitt
Troubleshooting
Hilfe, zur Lösung des Problems.
Erweiterte Informationen
Tuning des Hochstartens
Standardmäßig wartet die
WrapperStartStopApp-
Klasse 2 Sekunden auf die Fertigstellung der Main-Methode der User-Anwendung.
Danach nimmt sie an, dass die Anwendung gestartet wurde und erstattet einen Bericht an den Wrapper-Prozess.
Dies wird gemacht, weil viele User-Anwendungen mit Main-Methoden geschrieben sind, die während der Ausführung der Anwendung keinen Wert zurückgeben.
In solchen Fällen gibt es keinen zuverlässigen Weg für die WrapperStartStopApp-Klasse, mitzuteilen,
wann und ob die Anwendung das Hochstarten fertiggestellt hat.
Wenn jedoch bekannt ist, dass die Main-Methode der Anwendung einen Wert zurückgibt nachdem sie gestartet wurde,
wäre es für den Wrapper am besten, zu warten bis dies abgeschlossen ist, bevor er die Ausführung fortsetzt.
waitForStartMain Systemeigenschaft:
Für Main-Methoden, die auf diese Art Werte zurückgeben, sucht die WrapperStartStopApp nach der
org.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain
Systemeigenschaft.
Wenn sie auf TRUE eingestellt ist, wird die WrapperStartStopApp unbegrenzt auf die Fertigstellung der Main-Methode warten.
Unendlich zu warten ist eine vorteilhafte Option,
wenn gewiss ist, dass die Main-Methode zeitnah antworten wird.
Andererseits wird der Wrapper während er unbegrenzt wartet,
während des Hochfahrens niemals aufgeben, unabhängig davon, wie lange es dauert.
Wenn die Möglichkeit besteht, dass der Hochstarten-Vorgang hängen könnte, ist es besser
die org.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait
Systemeigenschaft auf die maximale Wartezeit einzustellen.
Zum Beispiel um bis zu 5 Minuten (300 Sekunden) auf die Fertigstellung der Main-Methode beim Hochstarten zu warten,
stellen Sie die Eigenschaft wie folgt auf 300 ein:
Die Main-Methoden vieler Anwendungen sind darauf ausgelegt, keinen Wert zurückzugeben.
In diesen Fällen müssen Sie sich entweder an die üblichen 2-Sekunden-Timeoutzeit beim Hochstarten halten oder ein etwas längeres Timeout festlegen, indem Sie die
maxStartMainWait-Eigenschaft nutzen, um die Zeit zu simulieren, die Ihre Anwendung zum Hochstarten benötigt.
WARNING
Wenn TRUE in der waitForStartMain für eine Anwendung festgelgt ist,
deren start-Methode niemals einen Wert zurückgibt, erscheint der Wrapper zu Anfang korrekt zu funktionieren.
Der Wrapper befindet sich dann jedoch in einem ewig andauernden Wartestatus und wird nie in einen Start-Modus kommen, was bedeutet,
dass der Windows-Dienstmanager und mehrere der Fehlerbehebungsmechanismen des Wrappers nicht korrekt funktionieren werden.