Die Methode 2 nutzt die
WrapperStartStopApp-Helper-Klasse.
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 "stop", class
,wenn gestartet, löst das Herunterfahren durch das Verbinden mit der Anwendung aus.
Der Wrapper arbeitet mit dieser Art von Anwendung, indem er diese,
so wie in Methode 1, durch Nutzung der "start"-Klasse, startet und dann die Haupt-Methode der "stop"-Klasse aufruft, wenn es Zeit ist, die Anwendung herunterzufahren.
Wenn integriert mit dieser Methode 2
(WrapperStartStopApp Helper Klasse),
ersetzt die WrapperStartStopApp-Klasse die Main-Class 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
sowohl auch den Lebenszyklus der Anwendung.
Wenn der Wrapper via den WrapperManager eine Startnachricht to an die JVM sendet,
wird die Hauptmethode der "start"-Klasse der Anwendung aufgerufen.
Analog wird die Hauptmethode der "stop"-Klasse der Anwendung aufgerufen, wenn der Wrapper eine Stop-Nachricht an die JVM sendet.
Wenn die WrapperStartStopApp-Helper-Klasse gestartet wird,
muß es über die Klassennamen von beiden "start" und "stop" Klassen wie auch über die Parameter, die den Hauptmethoden jeder Klasse übergeben werden müssen.
Wie Sie sehen können, resultiert Anwendungsparameter
in eine Parameterliste, die etwas komplizierter als
die von der Methode 1 (WrapperSimpleApp) Helper.
Der erste Parameter, der der WrapperStartStopApp-Klasse übergeben wird
ist der vollständige Klassennamen der "start"Klasse. Dem folgt eine Zahl von Parametern für die Main-Methode der "start"-Klasse.
Nach den Parametern der "start"-Klasse kommt der komplette Klassenname der
"stop"-Klasse. Dem folgt ein TRUE/FALSE flag, welcher die WrapperStartStopApp-Klasse darüber informiert, ob sie auf die Beendigung aller Nicht-Daemon-Threads warten soll, bis diese sich selbst beendet. Dieses Flag wird dann von den Parametern der "stop"-Klasse, Parameter und Zahlen, gefolgt. Seien Sie nicht beunruhigt, wenn das aktuell etwas verwirrend klingen mag. Ein detailliertes Beispiel finden Sie 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 vorkommen kann, dass die genauen Schritte sich leicht unterscheiden, abhängig von der Version, die Sie installiert haben. Tomcat wurde in dem
/usr/lib-Verzeichnis installiert, mit de, Ergebnis eines
Tomcat-Homeverzeichnisses in /usr/lib/apache-tomcat-9.0.0.M13.
Installation der Wrapper-Dateien
Es gibt vier erforderliche Verzeichnisse, die konfiguriert werden müssen, damit der Wrapper genutzt werden kann.
NOTE
Bitte stellen Sie sicher, dass Sie die passenden Wrapper und libwrapper.so -Dateien benutzen,
die für die auszuführende Plattform erstellt wurden.
Es mag offensichtlich erscheinen, aber die Linux-Version des Wrappers wird zum Beispiel auf Solaris nicht funktionieren.
bin-Verzeichnis
Der Wrapper wird mit einem Shell-Skript ausgeliefert,(sh)
welches genutzt werden kann, um zuverlässig jede Java-Anwendung starten und beenden zu können, die
vom Java Service Wrapper gesteuert wird.
Als erstes kopieren Sie bitte die folgenden Dateien in das Tomcat bin-Verzeichnis:
Benennen Sie die Skript-Datei um, so dass sie ihren Anwendungsnamen widergibt.
{TOMCAT_HOME}/bin/tomcat
Öffnen Sie nun das Skript in einem Editorprogramm.
Wir müssen lange und kurze Namen festlegen,um richtig widerzugeben, dass das Skript genutzt wird, um Tomcat zu starten.
Sie werden zwei Variablen sofort hinter dem Skriptheader sehen
APP_NAME und APP_LONG_NAME.
Vorgeschlagene Werte für diese Variablen werden unten angezeigt.
Das Skript sollte keine zusätzliche Abänderung erfordern.
Jedoch geht es davon aus, dass die wrapper.conf Datei
sich innerhalb eines conf -Verzeichnis (eine Ebene höher,
../conf/wrapper.conf)befindet.
Wenn Sie wünschen, die wrapper.conf Datei woanders abzulegen, ist es erforderlich, dass die
WRAPPER_CONF -Variable im Skript entsprechend angepasst wird.
NOTE
Wichtig! Bevor Sie fortfahren, stellen Sie bitte sicher, dass für alle Dateien, die in das
bin Verzeichnis kopiert wurden, das ausführbare Bit gesetzt wurde.
lib-Verzeichnis
Kopieren Sie die Native-Library und die Wrapper jar-Datei ins Tomcat lib -Verzeichnis:
Die libwrapper.so Datei ist eine
Native-Library-Datei,
die von dem Teil des Wrappers benötigt wird, der innerhalb der JVM läuft.
Die wrapper.jar Datei beinhaltet alle Wrapper-Klassen.
NOTE
Beachten Sie bitte, dass die Native-Library
auf ein paar Plattformen geringfügig unterschiedliche Namensgebungsregeln folgt. Mögliche Namen beinhalten;
libwrapper.a,
libwrapper.sl,
libwrapper.so,
und libwrapper.jnilib.
In jedem Fall sollte die Datei kopiert werden, ohne dass die Dateiendung sich ändert.
conf-Verzeichnis
Sämtliche Konfigurationseinstellungen des Wrappers erfolgen über die Datei
wrapper.conf.
Der Standard-Ablageort für diese Datei befindet sich in einem conf-Verzeichnis
in dem Homeverzeichnis der Anwendung.
Bitte 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 dabei sicher die Endung .in
zu entfernen, so dass die Datei wrapper.conf lautet.
Sie sollten nun Folgendes haben:
{TOMCAT_HOME}/conf/wrapper.conf
Wenn Sie wünschen, die Konfigurationsdatei wrapper.confin ein anderes Verzeichnis zu verschieben,
können Sie es so tun.
Sie müssen die Skript-Dateien, die in das oben genannte bin-Verzeichnis kopiert wurden,
ändern, damit der neue Ort richtig widergegeben wird.
logs-Verzeichnis
Die Standard-Konfigurationsdatei wrapper.conf legt eine
wrapper.log Datei in ein logs-Verzeichnis
unterhalb des Homeverzeichnisses der Anwendung ab.
Tomcat hat bereits solch ein Verzeichnis, so ist dies bereits erledigt.
{TOMCAT_HOME}/logs
Wenn Sie wünschen, die wrapper.log Datei in einem anderen Verzeichnis abzulegen,
müssen Sie die wrapper.conf Datei editieren und die Wrapper-Logdatei
wrapper.logfile Eigenschaften anpassen, um den neuen Ort passend wiederzugeben.
Gehen Sie in die Java-Befehlszeile der Anwendung
Bevor der Wrapper konfiguriert werden kann, eine Anwendung zu starten, müssen Sie den kompletten
Java-Befehl kennen, der normalerweise benutzt wird.
Die meisten Anwendungen machen Gebrauch von einem Skript, um die Befehlszeile aufzubauen.
Diese Skripts neigen dazu, ziemlich unhandlich zu werden.
Aber tatsächlich ist die Fähigkeit, vermeiden zu können, mit ihnen arbeiten zu müssen, einer der Vorzüge in der Arbeit mit dem Wrapper.
Tomcat wird standardmäßig durch Nutzung eines Skripts gestartet
startup.sh und durch Nutzung eines Skripts beendet shutdown.sh.
Es wird gestartet, indem man zuerst das aktuelle Verzeichnis auf das
bin-Verzeichnis ändert und es dann von dort ausführt.
Wenn Sie startup.sh in einem Editor öffnen,
werden Sie nach kurzem Prüfen feststellen, dass Java tatsächlich nicht von diesem Skript aus gestartet wird.
Stattdessen von einem anderen Skript, welches sich catalina.sh, nennt.
Tomcat-Skripte sind sehr fortschrittlich und erlauben den User viel Konfigurationsarbeiten von der Befehlszeile aus zu tun.
Die Befehlszeile, die wir mit dem Wrapper nutzen, ist tatsächlich ein Snapshot von solch einer Konfiguration.
Dieses Beispiel nimmt an, dass keine Parameter, weder an Start- noch an Beenden-Skripts während dessen Ablauf übergeben werden.
Wenn Sie catalina.sh in einem Editor öffnen und ans Dateiende herunterscrollen, werden Sie einen Abschnitt sehen, der dem "start"-Befehl entspricht.
Es gibt zwei Optionen zum Starten der JVM - mit oder ohne einen Sicherheitsmanager. Um die Dinge einfach zu halten, werden wir die Version ohnen einen Sicherheitsmanager nutzen. Die Zeilen, in die wir interessiert sind, sehen wie folgt aus:
Die Mehrheit des Skripts hat die Aufgabe, systemspezifische Informationen zu sammeln und diese Information in Umgebungsvariablen zu speichern.
Die oben gezeigte Zeile expandiert dann die gesamten gesammelten Informationen in den finalen Java-Befehl, der die Anwendung startet.
Beim Betrachten des Quellcodes eines Skripts lernen Sie hoffentlich zu schätzen, dass Sie selbst nicht solche komplexen Skripts schreiben mussten.
Um den Wrapper zu konfigurieren, ist alles, was Sie wirklich brauchen, die schlußendlich erweiterte
Befehlszeile. Vielmehr als Lesen durch das ganze Skript und versuchen, es zu verstehen, werden wir einen einfachen Trick nutzen, um schlußendlich die Befehlszeile in der Konsole anzuzeigen.
Bitte editieren Sie das Skript catalina.sh, indem Sie es wie folgt ändern:
Wenn Sie jetzt noch einmal das Skript catalina.sh stop ausführen,
werden Sie etwas wie das Folgende sehen
(Ihre Ausgabe wird komplett auf einer Zeile sein):
Anders als die exec am Anfang der Herunterfahren-Zeile ,
und die weitergeleitete Ausgabe der Startzeile sind die beiden Befehlen fast identisch.
***The only difference is the parameter passed to the main class at the end.
The exec portion of the shutdown command and redirection to capture console output
are not required when using the Wrapper so the rest of this example will ignore those portions of the commands.
Der Wrapper kann auch mit dem Setzen von Elementen der Java-Befehlszeile in Anführungszeichen umgehen.
So ist es für diese nicht notwendig, dass diese in die unten angegebene Konfigurationsdatei
wrapper.conf übertragen werden müssen.
Ä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 führen Sie die unten genannten Änderungen durch.
NOTE
Wo die Eigenschaften unten erwähnt sind, werden Links zu den Beschreibungen genannt.
Nehmen Sie sich bitte die Zeit, die Beschreibungen von allen Eigenschaften,
die verändert wurden, zu überprüfen.
In vielen Fällen gibt es weitere Beschreibungen bezüglich ihrem Einsatz, die hier nicht aufgeführt werden.
Java Executable
Zuerst wird die Java-Programmdatei extrahiert und der Verzeichnispfad der
wrapper.java.command Eigenschaft zugewiesen:
wrapper.java.command=/opt/jdk1.8.0_45/bin/java
Java-Argumente
Die meisten Anwendungen liefern eine Zahl von Parametern an die Java-Programmdatei, sobald sie gestartet wird, übergeben werden.
Der Wrapper liefert besondere Eigenschaften für die Konfiguration von Dingen wie Speicher oder auch 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=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=/usr/lib/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=/usr/lib/apache-tomcat-9.0.0.M13/conf/logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Classpath
Als Nächstes kommt der Classpath, der unter Einsatz der
wrapper.java.classpath.<n> Eigenschaften konfiguriert wurde.
Der Wrapper erfordert, dass der Classpath in seine Einzelteile aufgeteilt wird.
Dann, auch weil wir den Wrapper benutzen, ist es notwendig, auch
die wrapper.jar Datei mit einzuschließen:
Die nächste Befehlskomponente, die genutzt wird, um Tomcat zu starten, ist die Main-Class, org.apache.catalina.startup.Bootstrap.
Die von Java beim Starten ausgeführte Main-Class ist spezifiziert unter Nutzung der
wrapper.java.mainclass-Eigenschaft.
Wie oben erwähnt; da wir die Helper-Klasse WrapperStartStopApp für das Starten und Beenden von Tomcat nutzen, werden wir den vollständigen Namen der Klasse als Main-Class spezifizieren.
Die Tomcat Main-Classes sind dann spezifiziert wie die unten genannten Anwendungsparameter.
Ausführliche Details zu diesen Eigenschaften sind verfügbar, wenn Sie die Seite
wrapper.app.parameter.<n> besuchen.
Anwendungsparameter erscheinen in der Java-Befehlszeile direkt hinter der Main-Class.
Wenn wir die WrapperStartStopApp-Helper-Klasse benutzen, muß viel Information bereitgestellt werden, über beides die "start" und "stop"-Klassen.
Diese Information beinhaltet den vollständigen Namen, die Parameterliste, die den Hauptmethoden übergeben werden and ein Flag, welches die Helper-Klasse informiert, ob es warten soll bis alle Threads, die keine Daemon-Threads sind, sich beendet haben, bevor es die JVM veranlässt, sich zu beenden.
Wir erklären wie folgt, wie diese Information programmiertechnisch umgesetzt wird.
Wir starten mit dem Anzeigen der Eigenschaftenwerte für die Tomcat-Anwendung.
Mehrere Kommentare wurden bereits oben hinzugefügt, insbesondere bezüglich dessen, was Sie normalerweise
in der wrapper.conf-Datei finden können.
Es wird einfach zu verstehen sein, was jede Eigenschaft bedeutet.
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 Konsistenz.
Das Flaggen-Kennzeichen an Parameterstelle #5 oben wird genutzt, um das Verhalten der
WrapperStartStopApp-Helper-Klasse zu steuern, wenn es die JVM beendet.
Wenn der Wrapper eine Beenden-Anforderung an die JVM sendet, dann antwortet WrapperStartStopApp durch Aufruf der Hauptmethode der "stop"-Klasse mit den konfigurierten Partametern.
Die Flagge oben kontrolliert controls what happens when that main method returns.
If the flag is FALSE then System.exit(0) will be called immediately.
When TRUE,WrapperStartStopApp will wait until all non-daemon
threads have completed before calling System.exit(0).
Das Letztere ist das Verhalten, welche das besten passende Beenden für Tomcat erlaubt.
Wenn TRUE spezifiziert ist, sich aber einer oder mehr Daemonen-Threads nicht beenden, dann wird der Wrapper die JVM, nachdem ihr Beenden-Timeout-Zeitraum abgelaufen ist, diese zwangsweise beenden.
Der Timeout-Zeitraum ist standardmäßig auf 30 Sekunden festgelegt.
Threads, die keine Daemon-Threads sind, werden gezählt, indem sie über alle Threads im System iteriert werden und das Zählen von diesen, dessen isDaemon-Methode FALSE zurückliefert.
Leider wird diese Zählung aufgrund der Existenz von Systemthreads in den meisten JVMs niemals wirklich "0" (Null) erreichen.
In den meisten Oracle Hotsopt JVMs gibt es einen Systemthread, der kein Daemon ist.
Damit das Beenden korrekt funktioniert, muss diese Systemthreadzahl auch korrekt sein.
Es kann duch Definieren einer Systemeigenschaft festgelegt werden:
org.tanukisoftware.wrapper.WrapperStartStopApp.systemThreadCount
Der Standardwert ist "1 Thread".
NOTE
Wenn die Hauptmethode der stop-Klasse System.exit von innerhalb seines Hauptfadens aufruft, wird dieser Thread tatsächlich durch diesen Aufruf geblockt.
Der Wrapper vermeidet einen Deadlock, indem er dies 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 tunmöglichst vermieden werden.
Dieser Fall kann getestet werden, um die wrapper.debug=TRUE-Eigenschaft zu aktivieren und dann die Logdatei während des Beenden-Prozesses zu beobachten.
Bibliothekspfad
Um den Wrapper zu nutzen, gibt es eine weitere Eigenschaft, die gesetzt werden muss.
Der Wrapper nutzt eine native Bibliothek, um die Interaktionen mit dem System zu regeln.
Diese Bibliotheksdateilibwrapper.so muß in dem
Bibliothekspfad spezifiziert werden, der auch der JVM übergeben 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.
Der Bibliothekspfad wird durch Festlegen der
wrapper.java.library.path.<n>
Eigenschaften festgelegt.
Bitte beachten Sie, dass, während diese Konfigurationen auf dieser besonderen Maschine korrekt funktionieren,
diese sehr stark von der Verzeichnisstruktur und Plattform abhängen können.
Durch Nutzen der Tatsache, dass die Skripte des Wrappers stets das aktuelle Verzeichnis auf den Speicherort des Skripts festlegen, und durch Nutzen einer einzelnen Umgebungsvariablen,
sind wir in der Lage die oben genannten Eigenschaften zu ändern, so dass sie komplett plattform- und maschinenunabhängig sind.
Es wurde erwähnt, 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:
Tomcat kann nun einfach durch das Ausführen des Skripts
bin/tomcat console ausgeführt werden.
Aufgrund der Art, wie der Wrapper sein aktuelles Verzeichnis festlegt,
ist es nicht notwendig, dieses Skript von innerhalb des
bin-Verzeichnisses auszuführen.
Wie Sie sehen werden, wenn Sie einen Befehl auslassen, entsprechen die Skripte, die mit dem
Wrapper angeboten werden, meist gewöhnlichen Daemon-Skripten.
Sie akzeptieren
console,
start,
stop,
restart und
dump Befehle.
Die start,
stop, und
restart Befehle
sind für die meisten Daemon-Skripte üblich und werden genutzt, um den Wrapper und seine Anwendung als einen Daemon-Prozess zu steuern.
Der status-Befehl
kann genutzt werden, um herauszufinden, ob der Wrapper aktuell läuft oder nicht.
Der console-Befehl startet den Wrapper in der aktuellen Shell,
ermöglicht es, die Anwendung zwangsweise mit STRG-C zu beenden.
Der letzte Befehl dump schickt ein "kill -3"-Signal an den Wrapper,
der bewirkt, dass seine JVM einen kompletten Thread-Dump durchführt.
Glückwunsch. Ihre Anwendung sollte nun betriebsbereit laufen.
Wenn Sie irgendwelche Probleme antrafen, sehen Sie bitte in den Bereich
Troubleshooting,
um Hilfe mit dem Auffinden eines Problems zu erhalten.
Erweitert
Tuning des Startens
Standardmäßig wartet die
WrapperStartStopApp-Klasse 2 Sekunden, damit sich die Main-Methode für die Anwendung des Users beenden kann.
Nach dieser Zeit nimmt sie an, dass die Anwendung gestartet wurde und teilt dies dem Wrapper-Prozess mit. Dies erfolgt, weil es viele User-Anwendungen gibt, die mit Main-Methoden geschrieben sind, die während der Anwendungsnutzung keine Rückgabewerte liefern.
In solchen Fällen gibt es keine sicheren Werte für die
WrapperStartStopApp-Klasse darüber zu informieren, ob und wenn ja, wann die Anwendung ihren Startvorgang abgeschlossen hat.
Wenn es jedoch bekannt ist, dass die Main-Methode der Anwendung einen Rückgabewert liefert, sobald die Anwendung gestartet ist, wäre es ideal für den Wrapper darauf zu warten bis der Vorgang abgeschlossen ist, bevor er fortsetzt.
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.
Zeitlich unbegrenzte Warteschleifen können eine vorteilhafte Option sein, wenn bekannt ist, dass
die Main-Methode zeitnah ein Ergebnis zurückliefern wird.
Andererseits sollte auch beachtet werden, dass der Wrapper unendlich lang wartet,
da er niemals bei einem Startvorgang aufgeben wird, ungeachtet wie lange dieser 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, damit 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
?
Please check the English version for a more recent version of this text.
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.