Die vierte und letzte Methode ist die, die WrapperJarApp-Helper-Klasse zu nutzen, um die Anwendung zu starten.
Dies ist eine andere einfache Art der Integration mit dem Wrapper, wenn die Anwendung bereits konfiguriert ist, um als eine jar-Programmdatei ausgeführt zu werden.
Es gibt jedoch einige Dinge zu beachten, wenn Sie diese Methode nutzen.
Wenn der Wrapper die JVM beendet, gibt es keinen direkten Aufruf an eine Anwendung, mit der Aufforderung, sich korrekt zu beenden.
Vielmehr beendet der Wrapper die JVM durch den Aufruf von System.exit() von innerhalb der JVM.
Wenn die Anwendung ihren eigenen
Shutdown-Hook registriert hat, wird dieser aufgerufen werden und gibt der Anwendung die Möglichkeit, sich korrekt zu beenden.
Wenn andererseits ein Shutdown-Hook nicht registriert wurde, dann wird sich die Anwendung plötzlich - gleich dem Drücken von STRG-C in der Konsole (Befehlszeilenfenster) - beenden.
Beide Fälle, mit oder ohne eines Shutdown-Hooks, liefern das genau gleiche Verhalten, so als ob die Anwendung ohne den Wrapper laufen würde.
Bei der Integration mit dieser Methode 4 ersetzt die WrapperJarApp Helper-Klasse die Main-Klasse einer Anwendung.
Dies gibt der WrapperJarApp-Klasse eine Möglichkeit, den
WrapperManager sofort zu initialisieren und die JVM mit dem Wrapper zu registrieren.
Die WrapperJarApp-Klasse steuert jede Aktion mit dem Wrapper sowohl die Einsatzdauer einer Anwendung.
Wenn der Wrapper eine Startmeldung an die JVM via des WrapperManagers sendet,
wird das jar-Verzeichnis geprüft und seine konfigurierte Main-Class aufgerufen.
Die WrapperJarApp erstellt einen neuen Klassenlader, der imstande ist, Klassen von der ausführbaren jar-Datei wie auch von anderen jar-Dateien zu laden, auf die von innerhalb ihrer Verzeichnisdatei Bezug genommen wird.
Die WrapperJarApp-Helper-Klasse wird darüber informiert, wie die Anwendung durch Übergabe des absoluten oder relativen Speicherpfads von der ausführbaren jar-Datei zu starten ist; gefolgt von zusätzlichen Anwendungsparametern zur Hauptmethode der WrapperJarApp.
Detaillierte Anweisungen
Dieser Abschnitt führt Sie durch eine detaillierte Erklärung, wie JBoss zu konfigurieren ist, um innerhalb des Wrappers ausgeführt zu werden.
Die meisten anderen Anwendungen, die als ausführbare jars eingesetzt werden, können durch die gleiche Schrittfolge integriert werden.
Installation JBoss
Dieses Tutorial startet mit einer Neuinstallation von JBoss.
Wir nutzten JBoss EAP 7.0.0; die genauen Schritte können sich leicht unterscheiden, je nachdem welche Version installiert ist.
Nach dem Download von JBoss entpacken Sie die Dateien an einen Ort. In diesem Tutorial nutzen wir den Ordner D:\JBoss. Dann erstellen Sie die folgenden Ordner:
D:\JBoss\lib
D:\JBoss\conf
D:\JBoss\logs
Installation der Wrapper Dateien
Nachdem Sie den Wrapper heruntergeladen haben, entpacken Sie die Dateien an einen Ort, auf den mit {WRAPPER_HOME} Bezug genommen wird.
Es gibt vier Verzeichnisse, deren Konfiguration erforderlich ist, um in der Lage zu sein, den Wrapper zu nutzen.
bin-Verzeichnis
Zuerst kopieren Sie die folgenden Dateien in das bin-Verzeichnis von JBoss:
Benennen Sie die 3 Batch-Dateien um, damit der Name Ihrer Anwendung wiedergegeben wird.
Stellen Sie bitte sicher, die .in-Dateiendungen zu entfernen, so dass die Dateien alle auf .bat enden.
(Abhängig von den Einstellungen des Datei-Explorers auf Ihrem Computer kann es vorkommen, dass Sie Dateiendungen nicht sehen.)
Die wrapper.exe-Datei ist die eigentliche Wrapper-Programmdatei.
Die drei Batch-Dateien werden genutzt, um JBoss in einer Konsole auszuführen, und um diese als Windows Dienst zu installieren und deinstallieren.
Diese Batch-Dateien sollten keine Änderung benötigen.
Sie setzen voraus, 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 an einen anderen Ort zu verschieben, dann müssen die 3 Batch-Dateien passend geändert werden.
lib-Verzeichnis
Kopieren Sie die folgenden zwei Dateien in das JBoss lib-Verzeichnis:
Die wrapper.dll-Datei ist eine native Bibiliotheksdatei, die
von dem Teil des Wrappers benötigt wird, welcher innerhalb der JVM abläuft.
Die wrapper.jar-Datei enthält alle Wrapper-Klassen.
conf-Verzeichnis
Der Wrapper erfordert eine Konfigurationsdatei "wrapper.conf" für jede Anwendung.
Der Standardspeicherort 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 Hudson.
{WRAPPER_HOME}\src\conf\wrapper.conf.in
Benennen Sie die Datei um und stellen Sie sicher, dass die .in-Endung entfernt wird, so dass die Datei als wrapper.conf bezeichnet wird.
Sie sollten nun haben:
{JBOSS_HOME}\conf\wrapper.conf
Wenn Sie die Konfigurationsdatei wrapper.conf verschieben möchten, können Sie dies tun. Sie müssen dann die Batch-Dateien, die Sie in das oben genannte bin-Verzeichnis kopiert haben, abändern, damit der neue Speicherort richtig wiedergegeben wird.
logs-Verzeichnis
Die Standard-Konfigurationsdatei wrapper.conf legt eine
wrapper.log-Datei in das JBoss logs-Verzeichnis ab.
{JBOSS_HOME}\logs
Wenn Sie wünschen, die wrapper.log-Datei in ein anderes Verzeichnis abzulegen, müssen Sie die wrapper.conf-Datei und die
wrapper.logfile-Eigenschaften abändern, damit der neue Speicherort richtig wiedergegeben wird.
Die Java-Befehlszeile
Die Java-Befehlszeile von einer ausführbaren jar ist ziemlich einfach.
Im Falle von JBoss würden Sie einfach zum JBoss-Verzeichnis wechseln und dann Folgendes ausführen:
Um die obengenannte Java-Befehlszeile mit dem Wrapper nutzen zu können, müssen die Befehlszeilkomponenten in einer Konfigurationsdatei aufgeteilt werden.
Öffnen Sie die wrapper.conf-Datei in einem Editor und führen Sie die unten genannten Änderungen durch.
NOTE
Für alle unten genannten Eigenschaften werden Links zu den Eigenschaften zur Verfügung gestellt.
Bitte nehmen Sie sich die Zeit, die Beschreibungen aller Eigenschaften, die verändert wurden, zu verstehen.
In vielen Fällen gibt es weitere Anwendungsbeispiele, auf die hier nicht extra eingegangen wird.
Java-Programmdatei
Zuallererst entpacken Sie die Java-Programmdatei und fügen den Speicherpfad der
wrapper.java.command-Eigenschaft hinzu:
wrapper.java.command=java
wrapper.jar
Der Wrapper erstellt die Anforderung, dass die wrapper.jar spezifiziert wird:
wrapper.jarfile=D:\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.
Klassenpfad
Als Nächstes kommt der Klassenpfad, der unter Nutzung der
wrapper.java.classpath.<n>-Eigenschaften konfiguriert wird.
Java erlaubt Ihnen normalerweise, beim Ausführen der -jar-Parameter nicht einen Klassenpfad zu spezifizieren. Aber diese Integration läuft etwas anders.
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>-Eigenschaft festgelegt.
In diesem Fall erfordert die Befehlszeile zum Starten von JBoss einige Anwendungsparameter.
Es ist notwendig, der WrapperJarApp-Helper-Klasse mitzuteilen, welche jar auszuführen ist.
Dies wird wie folgt getan:
Zusätzliche Parameter von Java werden unter Nutzung der
wrapper.java.additional.<n>-Eigenschaft festgelegt.
Einige Parameter müssen für die JVM gesetzt werden, damit JBoss korrekt startet.
Um den Wrapper zu nutzen, muss noch eine andere Eigenschaft festgelegt werden.
Der Wrapper nutzt eine native Bibliotheksdatei, um Interaktionen mit dem System zu steuern.
Diese Bibliotheksdateiwrapper.dll muss auf dem Bibliothekspfad, der von der JVM zur Verfügung gestellt wird, spezifiziert werden.
JBoss besitzt keine eigenen nativen Bibliotheken, aber wenn es diese hätte, müssten die Verzeichnisse, wo sie sich befänden, auch spezifiziert werden.
Der Bibliothekspfad wird durch das Setzen der
wrapper.java.library.path.<n>-Eigenschaften festgelegt.
Beachten Sie bitte, dass obwohl diese Konfigurationen auf unserer Testmaschine korrekt ausgeführt wurden, dies aber auch sehr stark verzeichnisstruktur- und plattformabhängig ist.
Indem wir von dem Wissen Nutzen ziehen können, dass der Wrapper stets das Arbeitsverzeichnis auf den Speicherort der wrapper.exe-Datei festlegt und wir darauf über eine einfache Umgebungsvariable zugreifen können, sind wir in der Lage, die oben genannten Eigenschaften so zu ändern, dass diese komplett plattform- und maschinenunabhängig werden:
Der abschließende Schritt ist es, die Windows Diensteigenschaften festzulegen. Wir werden nur die Eigenschaften festlegen, die geändert werden sollten.
Aber es gibt noch weitere verfügbare Eigenschaften; sehen Sie bitte dafür in die Dokumentation, um mehr Details zu ihrer Anwendung zu erhalten. Vorgeschlagene Werte für diese Variablen werden unten angezeigt.
Die Eigenschaften werden in der wrapper.conf-Datei festgelegt, die sich in dem Ordner conf der Wrapper-Installation befindet.
Ausprobieren.
JBoss kann nun durch einfaches Ausführen der Batch-Datei bin\myJBoss.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-Verzeichnis auszuführen.
Bitte versuchen Sie die Anwendung zuerst als eine Konsolenanwendung auszuführen, um die Konfiguration zu testen, bevor Sie versuchen, diese als ein Dienst zu starten.
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 und dump werden akzeptiert.
Das erste Mal, wenn JBoss startet, wird es seine Konfigurationsdateien innerhalb des Home-Verzeichnis des aktuellen Users erstellen. Bitte beachten Sie, dass es sich dabei sehr wahrscheinlich um einen unterschiedlichen Speicherort handelt, je nachdem ob die Anwendung als Dienst oder in einem Konsolenfenster ausgeführt wird.
Gratulation. Ihre Anwendung sollte nun korrekt laufen.
Wenn Sie irgendwelche Probleme angetroffen haben, sehen Sie bitte in den Abschnitt Troubleshooting bezüglich Hilfe zum Auffinden des Problems.