Die Methode 2 wird für die Nutzung der WrapperStartStopApp-Helper-Klasse eingesetzt.
Diese Methode liefert eine Möglichkeit der Integration mit Anwendungen wie Tomcat, die mit einer Klasse gestartet und mit einer anderen Klasse beendet werden.
Typischerweise öffnet diese Art von Anwendung einen Serversocket beim Starten, dessen Aufgabe es ist, auf eine Verbindung zu warten, die ein Beenden auslöst.
Das Beenden oder die stop-Klasse, sobald gestartet löst sie das Beenden aus, indem sie sich mit der Anwendung verbindet.
Der Wrapper arbeit mit diesem Anwendungstyp zusammen, indem er die Anwendung startet, so wie in der Methode 1 beschrieben
unter Nutzung der start-Klasse und dem Aufruf der Hauptmethode der
stop-Klasse, wenn es an der Zeit ist, die Anwendung zu beenden.
Durch die Integration mit dieser Methode 2 ersetzt die WrapperStartStopApp-Helper-Klasse die Main-Class einer Anwendung.
Dies gibt der WrapperStartStopApp-Klasse die Möglichkeit,
den WrapperManager sofort zu initialisieren und die JVM mit dem Wrapper zu registrieren.
Die WrapperStartStopApp-Klasse verwaltet dann die komplette Interaktion mit dem Wrapper sowohl die Aktivitätsdauer einer Anwendung.
Wenn der Wrapper via des WrapperManagers eine Startnachricht an die JVM versendet, dann wird die Main-Methode der start-Klasse der Anwendung aufgerufen.
Analog zur Situation, wenn der Wrapper eine Stop-Nachricht aussendet, wird die Haupt-Methode der stop-Klasse aufgerufen.
Wenn die WrapperStartStopApp-Helper-Klasse gestartet wird, muss sie über beide Klassennamen der start und stop-Klassen sowohl auch über alle Parameter, die den Main-Methoden jeder Klasse übergeben werden, informiert werden.
Wie Sie auf der Seite Anwendungsparameter sehen können, hat dies eine Parameterliste zur Folge, die etwas komplexer als die von der Methode 1 (WrapperSimpleApp) Helper-Klasse ist.
Der erste Parameter, der der WrapperStartStopApp-Klasse übergeben wird,
ist der vollständige Klassenname der start-Klasse.
Dem folgt eine Zahl von Parametern bezüglich der Main-Methode der start-Klasse, die als nächstes kommt.
Nach den Parametern der start-Klasse kommt der vollständige Name der stop-Klasse.
Dies wird durch eine TRUE/FALSE-flag-Markierung gefolgt, die die WrapperStartStopApp -Klasse darüber informiert, ob diese warten soll bis alle Threads, die keine Dämon-Threads sind, beendet sind, bevor diese sich selbst beendet.
Diese flag-Markierung wird dann von dem stop-Klassenparameter, Zähler und Parameter, gefolgt. Lassen Sie sich nicht verunsichern, wenn dies bis jetzt noch nicht ganz klar erscheint.
Ein detailliertes Beispiel folgt unten.
Detaillierte Anleitungen
Dieser Abschnitt führt Sie durch eine detaillierte Anleitung bezüglich wie eine Konfiguration aussehen kann,
um Tomcat innerhalb des Wrappers auszuführen.
Die meisten anderen Anwendungen können durch Abfolge der gleichen Schritte integriert werden.
Installation von Tomcat
Dieses Tutorial startet mit einer Neuinstallation von
Tomcat.
Wir nutzten die Tomcat 9.0.0.M13 Version, so dass es der Fall sein kann, dass sich die genauen Schritte leicht unterscheiden können, abhängig von der Version, die Sie installiert haben.
Tomcat wurde in dem root-Verzeichnis installiert, D:\,
was ein Tomcat-Homeverzeichnis von D:\apache-tomcat-9.0.0.M13 zur Folge hat.
Installation Wrapper-Dateien
Es gibt vier erforderliche Verzeichnisse, die konfiguriert werden müssen, damit der Wrapper genutzt werden kann.
bin-Verzeichnis
Zuerst kopieren Sie die folgenden 3 Dateien in das bin-Verzeichnis von Tomcat:
Benennen Sie die 3 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 Batch-Dateien werden genutzt, um Tomcat in einer Konsole auszuführen, und es als ein Windows Dienst zu installieren und zu deinstallieren.
Diese Batch-Dateien sollten keine Änderung benötigen.
Sie folgen der Annahme, dass sich die wrapper.conf-Datei innerhalb eines conf-Verzeichnis befindet(eine Ebene höher, ../conf/wrapper.conf).
Wenn Sie möchten, können Sie die wrapper.conf-Datei auch woanders speichern;
dann müssen die drei Batch-Dateien entsprechend passend 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 als wrapper.conf bezeichnet ist.
Sie sollten nun Folgendes haben:
{TOMCAT_HOME}\conf\wrapper.conf
Wenn Sie die Konfigurationsdatei wrapper.conf an einen anderen Ort verschieben möchten, steht es Ihnen frei, dies zu tun.
Sie müssen die in das oben genannte bin-Verzeichnis kopierten Batch-Dateien passend ändern, damit der neue Speicherort entsprechend richtig wiedergegeben wird.
logs-Verzeichnis
Die Standard-Konfigurationsdatei wrapper.conf legt eine wrapper.log-Datei in ein logs-Verzeichnis unterhalb des Home-Verzeichnis der Anwendung ab.
Tomcat verfügt bereits über ein solches Verzeichnis, dies ist bereits eingerichtet.
{TOMCAT_HOME}/logs
Wenn Sie die wrapper.log-Datei an einen anderen Ort speichern möchten, müssen Sie die wrapper.conf-Datei editieren
und die wrapper.logfile-Eigenschaften ändern, damit der Speicherort richtig wiedergegeben wird.
Die Java-Befehlszeile der Anwendung
Bevor der Wrapper konfiguriert werden kann, eine Anwendung zu starten,
müssen Sie den vollständigen Java-Befehl, der standardmäßig genutzt wird, kennen.
Die meisten Anwendungen nutzen eine Batch-Datei, um die eigentliche Befehlszeile aufzubauen.
Diese Batch-Dateien tendieren dazu, ziemlich unhandlich zu werden;
aber tatsächlich ist die Möglichkeit, das Schreiben von eigenen Batch-Dateien vermeiden zu können, einer der Vorzüge in der Arbeit mit dem Wrapper.
Tomcat wird standardmäßig durch Nutzung einer Batch-Datei namens startup.bat gestartet und durch Nutzung einer Batch-Datei namens shutdown.bat beendet.
Sie wird gestartet, indem zuerst das aktuelle Verzeichnis auf
bin-Verzeichnis geändert und diese dann von dort aus gestartet wird.
Wenn Sie die startup.bat-Datei in einem Editor öffnen, werden Sie nach kurzer Prüfüng merken, dass Java nicht von dieser Batch-Datei gestartet wird.
Stattdessen wird eine andere Batch-Datei, catalina.bat, aufgerufen.
Die Skripts von Tomcat sind sehr flexibel, erweitert gestaltet und erlauben so dem User, einen Großteil der Konfiguration
via der Befehlszeile zu erledigen.
Die Befehlszeile, die wir erfassen und mit dem Wrapper nutzen werden, ist tatsächlich eine Momentaufnahme solch einer Konfiguration. Dieses Beispiel geht davon aus, dass keine Parameter übergeben werden, weder an Skripts zum Starten noch zum Beenden.
Wenn Sie die catalina.bat-Datei in einem Editor öffnen und ganz ans untere Ende der Datei herunterscrollen, werden Sie vier Zeilen sehen, die Java startet.
Mit den Standard-Einstellungen, die wir nutzen, werden die ersten dieser genutzt werden.
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 schlußendlichen Java-Befehl, der die Anwendung startet.
Wir hoffen, dass Sie bei einem Blick in den Quellcode der Batch-Datei
zu schätzen wissen, dass Sie selbst nicht solche komplexen Skripts schreiben müssen.
Um den Wrapper zu konfigurieren ist alles, was Sie wirklich brauchen, die erweiterte Befehlszeile.
Statt dem Durchlesen des ganzen Skripts und dem Versuch dieses zu verstehen,
nutzen wir einen einfachen Trick, um die Befehlszeile in der Konsole anzuzeigen.
Editieren Sie die Batch-Datei 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 noch einmal verkürzt, damit diese auf den Bildschirm passt.)
Wir müssen nun die gleiche Vorgehensweise für die Batch-Datei 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. Dies ist weil beide Dateien, startup.bat und shutdown.bat, mit der Änderung nur eines Parameters catalina.bat aufrufen.
Bis auf start Tomcat zu Beginn der Startzeile, sind die zwei Befehl nahezu identisch.
Der einzige Unterschied ist der, dass der Parameter am Ende der Main-Class übergeben 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, so wird der Rest dieses Beispiels diesen Anteil des Befehls ignorieren.
Der Wrapper weiß auch mit dem Setzen von Teilen der aufzubauenden Java-Befehlszeile in Anführungszeichen unzugehen. So ist es für diese nicht notwendig, in die Konfigurationsdatei wrapper.conf unten übertragen zu werden.
Ändern der "wrapper.conf"-Datei
Um die oben genannte Befehlszeile mit dem Wrapper zu nutzen,
müssen wir die Komponenten der Befehlszeile in einer Konfigurationsdatei aufteilen.
Öffnen Sie hierzu bitte die wrapper.conf
-Datei in einem Editor und führen Sie die Änderungen, wie unten angezeigt, durch.
NOTE
Wir haben ein paar Links zur Verfügung gestellt, wo Sie dann auch die Beschreibung der erwähnten Eigenschaften finden werden. Bitte nehmen Sie sich die Zeit, die Beschreibungen aller Eigenschaften, die geändert wurden, durchzugehen.
In vielen Fällen können Sie vollständige Details zu ihrer Nutzung finden, die hier nicht erwähnt wurden.
Java-Programmdatei
Zuallererst entpacken Sie die Java-Programmdatei und weisen Sie den Speicherpfad der Eigenschaft zu:
wrapper.java.command
wrapper.java.command=D:\jdk1.8.0_45\bin\java
Java-Argumente
Die meisten Anwendungen bieten für die Java-Programmdatei, wenn sie gestartet wird, eine Zahl an Parametern an.
Der Java Service Wrapper bietet besondere Eigenschaften an, um Dinge, wie Speicher sowohl als auch Klassen und Bibliothekspfade zu konfigurieren.
Diese werden unten behandelt; jedoch werden alle anderen Einstellungen durch Nutzung der Reihe an Eigenschaften von
wrapper.java.additional.<n> konfiguriert.
Die Tomcat-Befehlszeile besitzt mehrere dieser 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 keine dieser Pfade jemals Anführungszeichen enthalten wird. Sehen Sie bitte die Eigenschaften-Dokumentation in Bezug darauf, wie man mit Eigenschaften, die Leerzeichen enthalten, umgehen kann.
Classpath
Nun haben wir den Klassenpfad, der unter Nutzung der Eigenschaften,
wrapper.java.classpath.<n>, konfiguriert wird.
Der Wrapper erfordert, dass der Klassenpfad in seine einzelnen Elemente aufgeteilt wird.
Da wir den Java Service Wrapper nutzen, ist es notwendig, die wrapper.jar-Datei ebenfalls hinzuzufügen:
Die nächte Befehlskomponente, die genutzt wird, um Tomcat zu starten ist die Main-Class, org.apache.catalina.startup.Bootstrap.
Die Main-Class, die beim Start von Java ausgeführt wird, wird durch die Nutzung der
wrapper.java.mainclass-Eigenschaft spezifiziert.
Wie oben erwähnt; da wir die WrapperStartStopApp
Helper-Klasse nutzen, um Tomcat zu starten und zu beenden, werden wir den vollständigen Namen der Klasse als Main-Class spezifizieren.
Die Hauptklassen von Tomcat sind dann als Anwendungsparameter unten spezifiziert.
Vollständige Details für die Konfiguration dieser Eigenschaften sind verfügbar via
wrapper.app.parameter.<n>
Anwendungsparameter erscheinen in der Java-Befehlszeile, direkt nach der Main-Class.
Wenn wir die WrapperStartStopApp-Helper-Klasse nutzen, muss viel Information über beide start und stop-Klassen zur Verfügung gestellt werden.
Diese Information beinhaltet den vollständigen Namen der Klassen und die Liste an Parameter, die ihren Main-Methoden übergeben wurden, und eine Flag-Kennzeichnung, die die Helfer-Klassen anweist, ob diese darauf warten sollen oder nicht, dass alle Threads, die keine Daemon-Threads sind, sich beenden, bevor die Beendigung der JVM herbeigeführt wird.
Wir erklären wie folgt, wie diese Information programmtechnisch umgesetzt wird.
Wir beginnen, indem wir die Eigenschaftswerte für die Tomcat-Anwendung vorstellen.
Mehrere Kommentare wurden bereits oben hinzugefügt, insbesondere darüber, was Sie normalerweise
in der wrapper.conf-Datei finden können.
Es wird einfach zu verstehen sein, was jede Eigenschaft bedeutet.
Wir schlagen vor. dass Sie diese Kommentare Ihrer Konfigurationsdatei wrapper.conf auch hinzufü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 Paramterzähler ist erforderlich, um die stop-Klasse in der Parameterliste zu bestimmen.
Der zweite Zähler existiert aus Gründen der Konsistenz.
Die Kennzeichnung parameter #5 oben wird genutzt, um das Verhalten der
WrapperStartStopApp-Helper-Klasse zu steuern, wenn diese die JVM beendet.
Wenn der Wrapper eine Aufforderung zum Beenden der JVM aussendet, antwortet WrapperStartStopApp, indem es die Haupt-Methode der stop-Klasse mit den konfigurierten Parametern aufruft.
Die flag-Markierung oben regelt, was passiert, wenn die Main-Methode einen Rückgabewert liefert.
Wenn die flag-Markierung FALSE ist, dann wird System.exit(0) sofort aufgerufen.
Wenn TRUE, wird WrapperStartStopApp so lange warten bis alle Threads, die keine Daemon-Threads sind, sich beendet haben, bevor System.exit(0) aufgerufen wird.
Das Letztere ist das Verhalten, welche das technisch sauberste Beenden von Tomcat ermöglicht.
Wenn TRUE spezifiziert wird, aber die Beendigung von einem oder mehreren Daemonen-Threads nicht erfolgt, dann wird der Wrapper zwangsweise die JVM beenden, nachdem ihre Shutdown-Timeout-Zeit abgelaufen ist.
Die standardmäßig gesetzte Timeout-zeit beträgt 30 Sekunden.
Threads, die keine Daemon-Threads sind, werden gezählt, indem sie wiederholend über alle Threads im System durchlaufen werden und diese Threads zählend, deren isDaemon-Methode den Rückgabewert FALSE liefert.
Glücklicherweise erreicht dieser Zähler in der Realität aufgrund der Existenz von Systemthreads auf den meisten JVMs niemals "0" (Null).
In den meisten Oracle Hotsopt JVMs, in denen es einen Systemthread gibt, der kein Daemon ist.
Damit der Beenden korrekt funktioniert, muss dieser Zähler für Systemthreads auch korrekt sein.
Er kann durch die Definition einer Systemeigenschaft festgelegt werden:
Der Standardwert von
org.tanukisoftware.wrapper.WrapperStartStopApp.systemThreadCount ist 1 Thread.
NOTE
Wenn die Main-Methode der stop-Klasse System.exit von innerhalb seiner Main-Methode aufruft, wird der Thread tatsächlich durch den Aufruf blockiert.
Der Wrapper vermeidet einen Deadlock, indem er dies entdeckt und mit dem Beenden nach 5 Sekunden fortfährt.
Jedoch kann dies dazu führen, dass die Anwendung sich nicht selbst korrekt beenden kann, und sollte daher vermieden werden, wenn möglich.
Dieser Fall kann durch Aktivieren der wrapper.debug=TRUE Eigenschaft getestet werden.
Danach prüfen Sie bitte die Logdatei während des Beenden-Prozesses.
Bibliotheksverzeichnis
Um den Wrapper zu nutzen, gibt es eine weitere Eigenschaft, die gesetzt werden muss.
Der Wrapper nutzt eine native Bibliothsdsatei, um die Interaktionen mit dem System zu regeln.
Diese Bibliotheksdateiwrapper.dll
muß in dem Bibliotheksverzeichnis, welches von der JVM zur Verfügung gestellt wird.
Tomcat hat keine eigenen nativen Bibliotheken, aber wenn es diese hätte, müsste die Verzeichnisse, in denen sie sich befänden, auch spezifiziert werden.
Bitte beachten Sie, dass, während diese Konfigurationen auf einer bestimmten Maschine korrekt funktionieren, dies sehr stark von der Verzeichnisstruktur und Plattform abhängen kann.
Es kann Nutzen aus der Tatsache gezogen werden, dass die Skripte des Wrappers stets das aktuelle Arbeitsverzeichnisauf den Speicherort der wrapper.exe-Datei festlegen.
Auch durch Nutzen einer einzelnen Umgebungsvariablen können wir die oben genannten Eigenschaften ändern.Dadurch sind sie vollständig plattform- und maschinenunabhängig.
Es wurde berichtet, dass Tomcat 5.0.28 nicht korrekt funktionieren würde, 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 abschliessende Schritt ist die Windows Diensteigenschaften festzulegen.
Wir werden nur die Eigenschaften festlegen, die geändert werden sollen.
Aber es sind auch ein paar andere verfügbar.
Sehen Sie bitte in die Dokumentation zu Details bezüglich Ihrer Anwendung.
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
Ausprobieren
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, diese Batch-Datei von innerhalb des bin-Verzeichnisses auszuführen.
Bitte versuchen Sie die Anwendung einmal als eine Konsolenanwendung auszuführen, um die Konfiguration zu überprüfen, bevor Sie versuchen, diese als ein Dienst auszuführen.
Glückwunsch. Ihre Anwendung sollte nun einsatzbereit sein.
Wenn Sie mit irgendwelchen Problemen konfrontiert wurden, werfen Sie bitte einen Blick in den
Abschnitt Troubleshooting
für Hilfe zur Problemlösung.
Erweitert
Tuning des Startens
Standardmäßig wartet die
WrapperStartStopApp-Klasse 2 Sekunden, damit sich die Main-Methode der User-Anwendung beenden kann.
Nach dieser Zeit nimmt es an, dass die Anwendung gestartet wurde und teilt diesem dem Wrapper-Prozess.
Dies erfolgt so, weil es viele User-Anwendungen gibt, die mit Main-Methoden geschrieben sind, die während des Anwendungseinsatzes keine Rückgabewerte zurückliefern.
In solchen Fällen gibt es keinen zuverlässigen Wert für die
WrapperStartStopApp-Klasse, darüber Bescheid zu wissen, ob und - wenn ja - wann die Anwendung ihren Startvorgang abgeschlossen hat.
Wenn es jedoch bekannt ist, dass die Main-Methode der Anwendung nach Anwendungsstart einen Rückgabewert liefert, wäre es ideal, wenn der Wrapper dann, bevor er fortsetzt, darauf wartet bis der Vorgang abgeschlossen ist.
waitForStartMain-Systemeigenschaft:
Für Main-Methoden, die auf dieser Art Rückgabewerte liefern, sucht die
WrapperStartStopApp
nach der Systemeigenschaft
org.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain.
Wenn diese auf TRUE gesetzt ist, wird WrapperStartStopApp
unendlich darauf warten, dass diese sich beendet.
Unbegrenzte Warteschleifen können eine vorteilhafte Option sein, wenn es bekannt ist, dass
die Main-Methode zeitnah ein Ergebnis zurückliefern wird.
Aber andererseits ist es so, dass der Wrapper unendlich lang wartet,
so dass er bei einem Startvorgang niemals aufgibt, ungeachtet wie lange dieser Vorgang dauert.
Daher kann es, wenn nicht auszuschließen ist, dass dieser Startvorgang hängen könnte, besser sein die Systemeigenschaft org.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait
auf die maximale Wartezeit einzustellen.
Um z.B. beim Starten bis zu 5 Minuten (300 Sekunden) zu warten bis sich die Main-Methode beendet,
legen Sie die Eigenschaft wie folgt auf 300 fest:
Die Main-Methoden vieler Anwendungen sind so konzipiert, dass sie keinen Rückgabewert liefern.
In diesen Fällen müssen Sie sich entweder mit der standardmäßigen Timeout-Zeit von 2 Sekunden beim Starten begnügen oder eine geringfügig längere Timeout-Zeit spezifizieren, indem Sie die
maxStartMainWait-Eigenschaft nutzen, um die Zeitdauer, die Ihre Anwendung zum Hochstarten braucht, zu simulieren.
WARNING
Wenn TRUE in waitForStartMain für eine Anwendung spezifiziert wurde, dessen start-Methode niemals einen Rückgabewert liefert, wird der Wrapper zuerst als korrekt funktionierend erscheinen.
Jedoch wartet der Wrapper tatsächlich in einer ewigen Warteschleife und wird nie in einen "laufenden Zustand" eintreten; das bedeutet, dass der Windows Dienstmanager und mehrere der Fehlerbehebungsmechanismen des Wrappers nicht korrekt funktionieren werden.