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:
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:
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:
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:
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
wrapper.jar
Der Wrapper erstellt die Anforderung, dass die wrapper.jar spezifiziert wird:
wrapper.jarfile=/usr/lib/jboss/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:
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 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.
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:
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:
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.
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.
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:
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.