Methode 2 - WrapperStartStopApp-Integration (Windows)

Overview

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:

{WRAPPER_HOME}\bin\wrapper.exe
{WRAPPER_HOME}\src\bin\App.bat.in
{WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in
{WRAPPER_HOME}\src\bin\UninstallApp-NT.bat.in

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.)

Sie sollten nun Folgendes vorfinden:

{TOMCAT_HOME}\bin\Tomcat.bat
{TOMCAT_HOME}\bin\InstallTomcat.bat
{TOMCAT_HOME}\bin\UninstallTomcat.bat

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:

{WRAPPER_HOME}\lib\wrapper.dll
{WRAPPER_HOME}\lib\wrapper.jar

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.)

%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -classpath "%CLASSPATH%" ...

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.)

echo %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -classpath "%CLASSPATH%" ...

Wenn Sie nun die Batch-Datei noch einmal ausführen, werden Sie etwas wie folgt in der Konsole sehen (Ihre Ausgabe wird komplett in einer Zeile sein):

"D:\jdk1.8.0_45\bin\java.exe"
  "-Djdk.tls.ephemeralDHKeySize=2048" 
  -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
  -Djava.util.logging.config.file="D:\apache-tomcat-9.0.0.M13\conf\logging.properties" 
  -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
  -classpath "D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar;D:\apache-tomcat-9.0.0.M13\bin\tomcat-juli.jar" 
  -Dcatalina.base="D:\apache-tomcat-9.0.0.M13" 
  -Dcatalina.home="D:\apache-tomcat-9.0.0.M13" 
  -Djava.io.tmpdir="D:\apache-tomcat-9.0.0.M13\temp" 
  org.apache.catalina.startup.Bootstrap start

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.bat catalina.bat aufrufen und nur einen Parameter ändern.

"D:\jdk1.8.0_45\bin\java.exe"
  "-Djdk.tls.ephemeralDHKeySize=2048" 
  -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
  -Djava.util.logging.config.file="D:\apache-tomcat-9.0.0.M13\conf\logging.properties" 
  -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
  -classpath "D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar;D:\apache-tomcat-9.0.0.M13\bin\tomcat-juli.jar" 
  -Dcatalina.base="D:\apache-tomcat-9.0.0.M13" 
  -Dcatalina.home="D:\apache-tomcat-9.0.0.M13" 
  -Djava.io.tmpdir="D:\apache-tomcat-9.0.0.M13\temp" 
  org.apache.catalina.startup.Bootstrap stop

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:

wrapper.jarfile=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar

WARNING

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:

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar

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.

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar
wrapper.java.classpath.2=D:\apache-tomcat-9.0.0.M13\bin\tomcat-juli.jar

Main-Klasse

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.

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

Anwendungsparameter

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 Bibliotheksdatei wrapper.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.

Der Bibliothekspfad ist durch die Nutzung der folgenden Eigenschaften festgelegt: wrapper.java.library.path.<n>.

wrapper.java.library.path.1=..\lib

Zusammenfassung

Zusammenfassend erhalten wir Folgendes:

wrapper.java.command=D:\jdk1.8.0_45\bin\java

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

wrapper.jarfile=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar
wrapper.java.classpath.2=D:\apache-tomcat-9.0.0.M13\bin\tomcat-juli.jar

wrapper.java.library.path.1=D:\apache-tomcat-9.0.0.M13\lib

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

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.

wrapper.java.command=%JAVA_HOME%/bin/java

wrapper.java.additional.1=-Dcatalina.base=..
wrapper.java.additional.2=-Dcatalina.home=..
wrapper.java.additional.3=-Djava.io.tmpdir=..\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=..\conf\logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

wrapper.jarfile=..\lib\wrapper.jar

wrapper.java.classpath.1=..\bin\bootstrap.jar
wrapper.java.classpath.2=..\bin\tomcat-juli.jar

wrapper.java.library.path.1=..\lib

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

NOTE

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:

wrapper.java.additional.1=-Djava.endorsed.dirs=../common/endorsed

Windows-Diensteigenschaften

(Siehe:Vom Wrapper unterstützte Windows-Versionen)

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.

Beispiel: (Wartezeit aktivieren)
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain=TRUE

maxStartMainWait Systemeigenschaft:

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:

Der Standardwert ist 2 Sekunden.

Beispiel: (300 Sekunden)
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait=300

NOTE

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.