World Map
Java Service Wrapper ist der einfachste Weg, um Ihr Produkt zuverlässiger, sicherer zu machen.
  • Free Trial
  • Buy Now
WrapperStartStopApp Integration (Windows)

Übersicht

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: 

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

Sie sollten nun Folgendes vorfinden: 

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

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: 

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

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

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

"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

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: 

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

Main-Class

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. 

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

Anwendungsparameter

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

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

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

Zusammenfassung

Zusammenfassend bekommen 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.java.classpath.1=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar
wrapper.java.classpath.2=D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar
wrapper.java.classpath.3=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, 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. 

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.java.classpath.1=..\lib\wrapper.jar
wrapper.java.classpath.2=..\bin\bootstrap.jar
wrapper.java.classpath.3=..\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 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: 

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

Windows Diensteigenschaften

(Sehen Sie bitte: Windows-Versionen, die seitens des Wrappers unterstützt werden)

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.

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

maxStartMainWait Systemeigenschaft:

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:

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

Copyright (c) 2004-2020, Tanuki Software, Ltd. All Rights Reserved.