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

Method 2 - WrapperStartStopApp Integration (Linux / UNIX)

Übersicht

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: 

{WRAPPER_HOME}/bin/wrapper
{WRAPPER_HOME}/src/bin/App.sh.in

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. 

APP_NAME="tomcat"
APP_LONG_NAME="Tomcat Application Server"

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: 

{WRAPPER_HOME}/lib/libwrapper.so
{WRAPPER_HOME}/lib/wrapper.jar

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: 

eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  -classpath "\"$CLASSPATH\"" \
  -Dcatalina.base="\"$CATALINA_BASE\"" \
  -Dcatalina.home="\"$CATALINA_HOME\"" \
  -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  org.apache.catalina.startup.Bootstrap "$@" start \
  >> "$CATALINA_OUT" 2>&1 "&"

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: 

#eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  #-classpath "\"$CLASSPATH\"" \
  #-Dcatalina.base="\"$CATALINA_BASE\"" \
  #-Dcatalina.home="\"$CATALINA_HOME\"" \
  #-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  #org.apache.catalina.startup.Bootstrap "$@" start \
  #>> "$CATALINA_OUT" 2>&1 "&"
echo "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  -classpath "\"$CLASSPATH\"" \
  -Dcatalina.base="\"$CATALINA_BASE\"" \
  -Dcatalina.home="\"$CATALINA_HOME\"" \
  -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  org.apache.catalina.startup.Bootstrap "$@" start"

Wenn Sie jetzt das Skript noch einmal ausführen, dann werden Sie etwas wie das Folgende sehen (Ihre Ausgabe wird komplett auf einer Zeile sein): 

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

Wir müssen nun den gleichen Vorgang für den Stop-Befehl wiederholen. Scrollen Sie in einem Editor hinunter, um den "stop"-Befehl zu finden: 

exec "$_RUNJAVA" $JAVA_OPTS \
  -classpath "$CLASSPATH" \
  -Dcatalina.base="$CATALINA_BASE" \
  -Dcatalina.home="$CATALINA_HOME" \
  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
  org.apache.catalina.startup.Bootstrap "$@" stop

Bitte ändern Sie diesen Abschnitt noch einmal wie folgt: 

#exec "$_RUNJAVA" $JAVA_OPTS \
  #  -classpath "$CLASSPATH" \
  #  -Dcatalina.base="$CATALINA_BASE" \
  #  -Dcatalina.home="$CATALINA_HOME" \
  #  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
  #  org.apache.catalina.startup.Bootstrap "$@" stop
echo "exec $_RUNJAVA $JAVA_OPTS" \
    "-classpath $CLASSPATH" \
    "-Dcatalina.base=$CATALINA_BASE" \
    "-Dcatalina.home=$CATALINA_HOME" \
    "-Djava.io.tmpdir=$CATALINA_TMPDIR" \
    "org.apache.catalina.startup.Bootstrap $@ stop"

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

exec /opt/jdk1.8.0_45/bin/java
  -Djdk.tls.ephemeralDHKeySize=2048 
  -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
  -classpath "/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar:/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar" 
  -Dcatalina.base="/usr/lib/apache-tomcat-9.0.0.M13" 
  -Dcatalina.home="/usr/lib/apache-tomcat-9.0.0.M13"
  -Djava.io.tmpdir="/usr/lib/apache-tomcat-9.0.0.M13/temp" 
  org.apache.catalina.startup.Bootstrap stop

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: 

wrapper.java.classpath.1=/usr/lib/apache-tomcat-9.0.0.M13/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar
wrapper.java.classpath.3=/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar

Main-Class

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. 

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

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

wrapper.java.library.path.1=/usr/lib/apache-tomcat-9.0.0.M13/lib

Zusammenfassung

Wir können wie folgt zusammenfassen: 

wrapper.java.command=/opt/jdk1.8.0_45/bin/java

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

wrapper.java.classpath.1=/usr/lib/apache-tomcat-9.0.0.M13/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar
wrapper.java.classpath.3=/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar

wrapper.java.library.path.1=/usr/lib/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 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. 

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

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

Ausprobieren

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.

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

maxStartMainWait Systemeigenschaft:

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:

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

? Please check the English version for a more up to date 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.

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