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

Methode 4 - WrapperJarApp Integration (Linux/UNIX)

Übersicht

Die vierte und letzte Methode nutzt die WrapperJarApp-Helper-Klasse, um die Anwendung zu starten. Dies ist ein anderer, einfacher Weg, es in den Wrapper einzubinden, wenn die Anwendung bereits bereits konfiguriert wurde, um als eine ausführbare jar-Datei ausgeführt zu werden.

Es gibt jedoch einige Dinge, über die Sie sich bewusst sein sollten, wenn Sie diese Methode nutzen. Wenn der Wrapper die JVM beendet, gibt es keinen direkten Aufruf einer Anwendung, die zum korrekten Beenden auffordert. Stattdessen wird der Wrapper die JVM beenden, indem die System.exit () von innerhalb der JVM aufgerufen wird. Wenn die Anwendung Ihre eigenen Shutdown Hook hat, wird dieser aufgerufen werden und gibt damit der Anwendung die Möglichkeit, sich korrekt zu beenden. Wenn andererseits kein Shutdown-Hook registriert ist, dann wird die Anwendung sich plötzlich beenden. Wie es beim Drücken von STRG-C in der Konsole (Befehlsfenster)der Fall ist. Beide Fälle, mit oder ohne Shutdown-Hook, liefern das das gleiche Ergebnis, so als ob die Anwendung ohne den Wrapper ausgeführt würde.

Durch Integration mit dieser Methode 4 (WrapperJarApp Helper_Class), ersetzt die WrapperJarApp-Klasse die Main-Class einer Anwendung. Dies gibt der WrapperJarApp-Klasse die Möglichkeit, den WrapperManager sofort zu initialisieren und die JVM mit dem Wrapper zu registrieren. Die WrapperJarApp-Klasse steuert den kompletten Austausch/Interaktion mit dem Wrapper sowohl auch den Lebenszyklus einer Anwendung. Wenn der Wrapper eine Start-Nachricht via des WrapperManagers an die JVM aussendet, wird das jar-Manifest geprüft und seine konfigurierte Main-Class wird aufgerufen. WrapperJarApp erstellt einen neuen ClassLoader, der imstande ist, Klassen von der executable jar-Datei zu laden sowohl als auch andere jar-Dateien, auf die von innerhalb dieser Manifest-Datei Bezug genommen wird.

Die WrapperJarApp-Helper-Klasse wird darüber informiert, wie sie die Anwendung starten kann, indem sie den relativen oder absoluten Speicherpfad der jar.Programm-Datei, gefolgt von einigen zusätztlichen Anwendungsparametern an die Main-Methode von WrapperJarAppübergibt.

Detaillierte Anleitungen

Dieser Abschnitt führt Sie durch eine ausführliche Erklärung darüber, wie JBoss zu konfigurieren ist, um innerhalb des Wrappers ausgeführt zu werden. Die meisten anderen Anwendungen, die als jars-Programmdateien eingesetzt werden, können durch das Folgen der gleichen Schritte integriert werden.

Installieren von JBoss EAP

Dieses Tutorial startet mit einer Neuinstallation von JBoss EAP. Wir nutzten JBoss EAP 7.0.0, so dass die genauen Schritte geringfügig unterschiedlich sein können, abhängig von der Version, die installiert wurde. Nach dem Download von JBoss entpacken Sie die Dateien an einen Platz. In diesem Tutorial nutzen wir das Verzeichnis /usr/lib/jboss. Dann erstellen Sie bitte die folgenden Ordner:

mkdir /usr/lib/jboss/lib
mkdir /usr/lib/jboss/conf
mkdir /usr/lib/jboss/logs

Installation der Wrapper-Dateien

Nach dem Download des Wrappers entpacken Sie die Dateien an eine Stelle, auf die wir mit {WRAPPER_HOME} verweisen. Es gibt vier Verzeichnisse, die konfiguriert werden müssen, um den Wrapper nutzen zu können.

NOTE

Stellen Sie bitte sicher, dass Sie den passenden Wrapper und die geeigneten libwrapper.so-Dateien nutzen, die für die Plattform erstellt wurden, auf der sie ausgeführt werden. Es klingt offensichtlich, aber die Wrapper Linux Version funktioniert z.B. nicht auf Solaris.

bin-Verzeichnis

Der Wrapper wird mit einem Shellskript ausgeliefert (sh), welches genutzt werden kann, um zuverlässig jede Java-Anwendung zu starten und zu beenden, die vom Java Service Wrapper gesteuert wird.

Zuerst kopieren Sie die folgenden Dateien in das bin-Verzeichnis von JBoss:

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

Benennen Sie die Skriptdatei um, um den Anwendungsnamen widerzugeben.

{JBOSS_HOME}/bin/myJBoss

Jetzt öffnen Sie das Skript in einem Editor. Wir müssen die langen und kurzen Namen so festlegen, dass das Skript genutzt wird, um JBoss zu starten. Sie werden zwei Variablen direkt am Anfang des Skripts sehen. APP_NAME und APP_LONG_NAME. Vorgeschlagene Werte für diese Variablen werden unten angezeigt.

APP_NAME="jboss"
APP_LONG_NAME="JBoss EAP"

Das Skript sollte keine zusätzliche Änderungen benötigen. Jedoch wird angenommen, dass die wrapper.conf Datei sich innerhalb des conf-Verzeichnis befindet (eine Ebene höher, ../conf/wrapper.conf). Wenn Sie wünschen, die wrapper.conf-Datei irgend woanders zu speichern, wird die WRAPPER_CONF-Variable des Skripts passend geändert werden müssen.

NOTE

Wichtig! Bevor Sie fortfahren, stellen Sie bitte sicher, dass alle ins bin-Verzeichnis kopierte Dateien ihr "X-Bit" - als Zeichen dafür, dass sie ausführbar sind - gesetzt haben.

lib-Verzeichnis

Kopieren Sie die folgenden 2 Dateien in das JBoss lib-Verzeichnis:

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

Die libwrapper.so-Datei ist eine native Bibliotheksdatei, die von dem Teil des Wrappers benötigt wird, der innerhalb der JVM ausgeführt wird. Die wrapper.jar-Datei enthält alle Wrapper-Klassen.

NOTE

Bitte beachten Sie, dass die native Bibliothek auf einigen Plattformen geringfügig unterschiedliche Namenskonventionen folgt. Mögliche Namen beinhalten libwrapper.a, libwrapper.sl, libwrapper.so, und libwrapper.jnilib. In jedem Fall sollte die Datei ohne Änderung der Dateinamenendung kopiert werden.

conf-Verzeichnis

Der Wrapper benötigt eine Konfigurationsdatei "wrapper.conf" für jede Anwendung. Der Standard-Speicherort für diese Datei ist in einem conf-Verzeichnis in dem Home-Verzeichnis der Anwendung. Kopieren Sie die folgende Vorlagendatei wrapper.conf.in in das conf-Verzeichnis von JBoss.

{WRAPPER_HOME}/src/conf/wrapper.conf.in

Benennen Sie die Datei um und stellen Sie sicher, die .in-Dateiendung zu entfernen, so dass die Datei mit wrapper.conf bezeichnet wird.

Sie sollten nun Folgendes haben:

{JBOSS_HOME}/conf/wrapper.conf

Wenn Sie wünschen, die Konfigurationsdatei wrapper.conf zu verschieben, sind Sie frei, dies zu tun. Das Skript, welches in das oben genannte bin-Verzeichnis kopiert wurde, muß angepasst werden, damit es den neuen Speicherort korrekt widergibt.

logs-Verzeichnis

Die Standard-Konfigurationsdatei wrapper.conf platziert eine wrapper.log-Datei in das logs-Verzeichnis von JBoss.

{JBOSS_HOME}/logs

Wenn Sie die wrapper.log-Datei in ein anderes Verzeichnis speichern möchten, müssen Sie die wrapper.conf-Datei editieren und die wrapper.logfile-Eigenschaft anpassen, damit der neue Speicherort richtig widergegeben wird.

Die Java-Befehlszeile

Die Java-Befehlszeile von einer ausführbaren jar-Datei ist ziemlich einfach. Im Fall von JBoss würden Sie einfach in das JBoss-Verzeichnis wechseln und Folgendes ausführen:

java -jar /usr/lib/jboss/jboss-modules.jar

Alle Argumente werden wie folgt weitergegeben:

java -jar /usr/lib/jboss/jboss-modules.jar arg1 arg2 arg3

Ändern der "wrapper.conf"-Datei

Um die oben genannte Java-Befehlszeile mit dem Wrapper nutzen zu können, müssen wir die Komponenten der Befehlszeile getrennt voneinander in eine Konfigurationsdatei aufteilen. Bitte öffnen Sie die wrapper.conf-Datei in einem Editor und führen Sie die unten genannten Änderungen durch.

NOTE

Für alle unten erwähnten Eigenschaften werden Links zu ihren Eigenschaften zur Verfügung gestellt. Bitte nehmen Sie sich die Zeit, die Beschreibungen von allen Eigenschaften, die verändert wurden, durchzusehen. In vielen Fällen gibt es weitere Details Ihrer Anwendung, die hier nicht erwähnt werden.

Java-Programmdatei

Zuerst entpacken Sie die Java-Programmdatei und weisen Sie den Speicherpfad der wrapper.java.command-Eigenschaft zu:

wrapper.java.command=java

Classpath

Als Nächstes kommt der Classpath, der unter Nutzung der wrapper.java.classpath.<n>-Eigenschaften konfiguriert wird. Java erlaubt Ihnen tatsächlich nicht, einen Classpath - als -jar-Parameter ausgeführt - zu spezifizieren; aber die Integration mit dem Wrapper funktioniert. Der Wrapper erfordert, dass seine wrapper.jar-Datei in dem Classpath spezifiziert wird:

wrapper.java.classpath.1=/usr/lib/jboss/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/jboss/jboss-modules.jar

Main-Class

Wenn Sie den Wrapper und die Helper-Klasse WrapperJarApp nutzen, führt Java die jar nicht direkt aus. Es ist notwendig, die Helper-Klasse als die Main-Class der Anwendung zu spezifizieren. Die Main-Class, die nach dem Start von Java ausgeführt wird, wird unter Nutzung der wrapper.java.mainclass-Eigenschaft wie folgt spezifiziert:

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp

Anwendungsparameter

Anwendungsparameter werden durch Nutzung der wrapper.app.parameter.<n>-Eigenschaften festgelegt. In diesem Fall erfordert die Befehlszeile, um JBoss zu starten, ein paar Anwendungsparameter. Es ist notwendig, die WrapperJarAppHelper-Klasse darüber zu informieren, welche jar ausgeführt wird. Dies wird wie folgt festgelegt:

wrapper.app.parameter.1=/usr/lib/jboss/jboss-modules.jar
wrapper.app.parameter.2=-mp
wrapper.app.parameter.3=/usr/lib/jboss/modules
wrapper.app.parameter.4=-jaxpmodule
wrapper.app.parameter.5=javax.xml.jaxp-provider
wrapper.app.parameter.6=org.jboss.as.standalone
wrapper.app.parameter.7=-Djboss.home.dir=/usr/lib/jboss
wrapper.app.parameter.8=-Djboss.server.base.dir=/usr/lib/jboss/standalone

Zusätzliche Parameter von Java

Zusätzliche Parameter von Java werden durch Nutzung der wrapper.java.additional.<n>-Eigenschaften festgelegt. Einige Parameter müssen für die JVM festgelegt werden, damit JBoss korrekt startet.

wrapper.java.additional.1=-D"[Standalone]"
wrapper.java.additional.2=-server
wrapper.java.additional.3=-XX:+UseCompressedOops
wrapper.java.additional.4=-Xms1303M
wrapper.java.additional.5=-Xmx1303M
wrapper.java.additional.6=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.7=-Djboss.modules.system.pkgs=org.jboss.byteman
wrapper.java.additional.8=-Djava.awt.headless=true
wrapper.java.additional.9=-Dorg.jboss.boot.log.file=/usr/lib/jboss/standalone/log/server.log
wrapper.java.additional.10=-Dlogging.configuration=file:/usr/lib/jboss/standalone/configuration/logging.properties
wrapper.java.additional.11=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
wrapper.java.additional.12=-Djava.util.logging.manager=org.jboss.logmanager.LogManager
wrapper.java.additional.13=-Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl

Library Path

Um den Wrapper zu nutzen, gibt es eine weitere Eigenschaft, die festgelegt werden muss. Der Wrapper benutzt eine native Bibliothek, um die Interaktionen mit dem System zu regeln. Die Bibliotheksdatei libwrapper.so muss in dem Bibliothekspfad, der der JVM bereitgestellt wird, angegeben werden.

JBoss hat keine eigenen nativen Bibliotheken, aber, wenn es diese haben würde, würden die Verzeichnisse, in denen diese sich befinden, auch spezifiziert werden müssen. Der Bibliothekspfad wird unter Nutzung der wrapper.java.library.path.<n>-Eigenschaften festgelegt.

wrapper.java.library.path.1=/usr/lib/jboss/lib

Zusammenfassung

Zusammengefasst erhalten wir Folgendes:

wrapper.java.command=java

wrapper.java.classpath.1=/usr/lib/jboss/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/jboss/jboss-modules.jar

wrapper.java.library.path.1=/usr/lib/jboss/lib

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp

wrapper.java.additional.1=-D"[Standalone]"
wrapper.java.additional.2=-server
wrapper.java.additional.3=-XX:+UseCompressedOops
wrapper.java.additional.4=-Xms1303M
wrapper.java.additional.5=-Xmx1303M
wrapper.java.additional.6=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.7=-Djboss.modules.system.pkgs=org.jboss.byteman
wrapper.java.additional.8=-Djava.awt.headless=true
wrapper.java.additional.9=-Dorg.jboss.boot.log.file=/usr/lib/jboss/standalone/log/server.log
wrapper.java.additional.10=-Dlogging.configuration=file:/usr/lib/jboss/standalone/configuration/logging.properties
wrapper.java.additional.11=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
wrapper.java.additional.12=-Djava.util.logging.manager=org.jboss.logmanager.LogManager
wrapper.java.additional.13=-Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl

wrapper.app.parameter.1=/usr/lib/jboss/jboss-modules.jar
wrapper.app.parameter.2=-mp
wrapper.app.parameter.3=/usr/lib/jboss/modules
wrapper.app.parameter.4=-jaxpmodule
wrapper.app.parameter.5=javax.xml.jaxp-provider
wrapper.app.parameter.6=org.jboss.as.standalone
wrapper.app.parameter.7=-Djboss.home.dir=/usr/lib/jboss
wrapper.app.parameter.8=-Djboss.server.base.dir=/usr/lib/jboss/standalone

Beachten Sie bitte, dass obwohl diese Konfigurationen auf unserer Testmaschine korrekt funktionieren, dies aber auch sehr stark verzeichnisstruktur- und plattformabhängig ist. Aus dem Wissen, dass der Wrapper stets das Arbeitsverzeichnis auf den Speicherort der wrapper.exe-Datei festlegt und darauf via eine einfache Umgebungsvariable zugegriffen werden kann, können wir Nutzen ziehen, um die oben genannten Eigenschaften so abzuändern, dass diese komplett plattform- und maschinenunabhängig sind:

set.JBOSS_HOME=/usr/lib/jboss

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

wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../jboss-modules.jar

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

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp

wrapper.java.additional.1=-D"[Standalone]"
wrapper.java.additional.2=-server
wrapper.java.additional.3=-XX:+UseCompressedOops
wrapper.java.additional.4=-Xms1303M
wrapper.java.additional.5=-Xmx1303M
wrapper.java.additional.6=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.7=-Djboss.modules.system.pkgs=org.jboss.byteman
wrapper.java.additional.8=-Djava.awt.headless=true
wrapper.java.additional.9=-Dorg.jboss.boot.log.file=%JBOSS_HOME%/standalone/log/server.log
wrapper.java.additional.10=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
wrapper.java.additional.11=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
wrapper.java.additional.12=-Djava.util.logging.manager=org.jboss.logmanager.LogManager
wrapper.java.additional.13=-Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl

wrapper.app.parameter.1=../jboss-modules.jar
wrapper.app.parameter.2=-mp
wrapper.app.parameter.3=%JBOSS_HOME%/modules
wrapper.app.parameter.4=-jaxpmodule
wrapper.app.parameter.5=javax.xml.jaxp-provider
wrapper.app.parameter.6=org.jboss.as.standalone
wrapper.app.parameter.7=-Djboss.home.dir=%JBOSS_HOME%
wrapper.app.parameter.8=-Djboss.server.base.dir=%JBOSS_HOME%/standalone

Austesten

JBoss kann nun durch einfaches Ausführen des Skripts bin/myJBoss 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, ist das Skript, welches mit dem Wrapper ausgeliefert wird, ein ziemlich gewöhnliches Standard-Daemon-Skript. Die Befehle console, start, stop, restart, and dump werden akzeptiert.

  • Die start,stop und restart-Befehle sind in den meisten Daemon-Skripten gebräuchlich und werden benutzt, um den Wrapper und seine Anwendung als ein Daemon-Prozess zu steuern.
  • Der Status-Befehl kann genutzt werden, um herauszufinden, ob der Wrapper gegenwärtig läuft oder nicht.
  • Der console-Befehl startet den Wrapper in der aktuellen Shell, ermöglicht es, die Beendigung der Anwendung mit STRG-C zu erzwingen.
  • Der abschliessende Befehl, dump, schickt ein "kill -3" Signal an den Wrapper, welcher seine JVM veranlässt, einen kompletten Thread-Dump durchzuführen.

Gratulation. Ihre Anwendung sollte nun korrekt laufen.

Wenn Sie auf irgendwelche Probleme gestossen sind, sehen Sie bitte in den Abschnitt Troubleshooting bezüglich Hilfe zum Auffinden des Problems.