La quatrième et dernière méthode consiste à utiliser la classe d'aide WrapperJarApp pour lancer l'application.
Il s'agit d'une autre façon simple de s'intégrer au Wrapper lorsque l'application est déjà
configurée pour s'exécuter en tant que jar exécutable.
Il y a cependant quelques points à prendre en compte lors de l'utilisation de cette méthode.
Lorsque le Wrapper arrête la JVM, aucun appel direct n'est effectué vers l'application pour lui demander de s'arrêter proprement.
Le Wrapper quitte plutôt la JVM en appelant System.exit() depuis l'intérieur de la JVM.
Si l'application a enregistré son propre Shutdown Hook,
celui-ci sera invoqué, donnant à l'application une chance de s'arrêter proprement.
Si, en revanche, aucun Shutdown Hook n'est enregistré, l'application se terminera brusquement
comme lorsque l'on appuie sur CTRL-C dans la console (fenêtre de commande).
Dans les deux cas, avec ou sans Shutdown Hook, le comportement est exactement le même que si l'application s'exécutait sans le Wrapper.
Lors de l'intégration avec cette Méthode 4 (classe d'aide WrapperJarApp),
la classe WrapperJarApp remplace la classe principale de l'application.
Cela donne à la classe WrapperJarApp l'occasion d'initialiser immédiatement le
WrapperManager et d'enregistrer la JVM auprès du Wrapper.
La classe WrapperJarApp gère ensuite toutes les interactions avec le Wrapper ainsi que le cycle de vie de l'application.
Lorsque le Wrapper envoie un message de démarrage à la JVM via le WrapperManager, le manifeste du jar
est inspecté et sa classe principale configurée est appelée.
La classe WrapperJarApp crée un nouveau ClassLoader capable de charger des classes à partir du fichier jar exécutable
ainsi que de tout autre fichier jar référencé dans son fichier manifeste.
On indique à la classe d'aide WrapperJarApp comment lancer l'application en passant l'emplacement absolu ou relatif du
fichier jar exécutable, suivi de tout paramètre d'application supplémentaire, à la méthode main de WrapperJarApp.
Instructions détaillées
Cette section vous guide à travers une explication détaillée de la configuration de
JBoss pour qu'il s'exécute dans le Wrapper.
La plupart des autres applications déployées sous forme de jars exécutables peuvent être intégrées en suivant les mêmes étapes.
Installer JBoss EAP
Ce tutoriel commencera avec une installation propre de JBoss EAP.
Nous avons utilisé JBoss EAP 7.0.0, les étapes exactes peuvent donc légèrement différer selon la version exacte installée.
Après avoir téléchargé JBoss, extraire les fichiers quelque part. Dans ce tutoriel, nous utiliserons le dossier /usr/lib/jboss.
Créer ensuite les dossiers suivants :
Après avoir téléchargé le Wrapper, extraire les fichiers quelque part ; cet emplacement sera référencé comme {WRAPPER_HOME}.
Quatre répertoires doivent être configurés afin de pouvoir utiliser le Wrapper.
NOTE
Assurez-vous d'utiliser le Wrapper approprié, ainsi que
les fichiers libwrapper.so compilés pour la plateforme d'exécution.
Cela peut sembler évident, mais la version Linux du Wrapper ne fonctionnera pas sous Solaris, par exemple.
répertoire bin
Le Wrapper est livré avec un script shell (sh)
qui peut être utilisé pour démarrer et arrêter de manière fiable toute application Java contrôlée par le Java Service Wrapper.
Tout d'abord, copier le fichier suivant dans le répertoire bin de JBoss (dans les versions plus anciennes du Wrapper, ce fichier s'appelait 'sh.script.in') :
Renommer le fichier script afin qu'il reflète le nom de l'application.
{JBOSS_HOME}/bin/myJBoss
Ouvrir maintenant le script dans un éditeur.
Nous devons définir les noms long et court pour indiquer que le script est utilisé pour lancer JBoss.
Vous verrez deux variables immédiatement après l'en-tête du script.
APP_NAME et APP_LONG_NAME.
Des valeurs suggérées pour ces variables sont indiquées ci-dessous.
APP_NAME="jboss"
APP_LONG_NAME="JBoss EAP"
Le script ne devrait nécessiter aucune modification supplémentaire.
Il suppose toutefois que le fichier wrapper.conf
se trouvera dans un répertoire conf (un niveau au-dessus, ../conf/wrapper.conf).
Si vous souhaitez placer le fichier wrapper.conf ailleurs, la variable WRAPPER_CONF
du script devra être modifiée en conséquence.
NOTE
Important ! Avant de poursuivre, veuillez vous assurer que tous les fichiers copiés dans le
répertoire bin ont leur bit d'exécution activé.
répertoire lib
Copier les deux fichiers suivants dans le répertoire lib de JBoss :
Le fichier libwrapper.so est un fichier de bibliothèque native
requis par la partie du Wrapper qui s'exécute au sein de la JVM.
Le fichier wrapper.jar contient toutes les classes du Wrapper.
NOTE
Notez que la bibliothèque native suit des conventions de nommage légèrement différentes sur certaines plateformes.
Les noms possibles incluent : libwrapper.a, libwrapper.sl, libwrapper.so et libwrapper.jnilib.
Dans tous les cas, le fichier doit être copié sans en modifier l'extension.
répertoire conf
Le Wrapper nécessite un fichier de configuration « wrapper.conf » pour chaque application.
L'emplacement standard de ce fichier est un répertoire conf dans le répertoire d'installation de l'application.
Copier le fichier modèle suivant wrapper.conf.in dans le répertoire conf de JBoss.
{WRAPPER_HOME}/src/conf/wrapper.conf.in
Renommer le fichier et veiller à supprimer l'extension .in
afin que le fichier s'appelle wrapper.conf.
Vous devriez maintenant avoir :
{JBOSS_HOME}/conf/wrapper.conf
Si vous souhaitez déplacer le fichier de configuration wrapper.conf, vous êtes libre de le faire.
Vous devrez modifier le script copié dans le répertoire bin ci-dessus pour refléter le nouvel emplacement.
répertoire logs
Le fichier de configuration par défaut wrapper.conf
placera un fichier wrapper.log dans le répertoire logs de JBoss.
{JBOSS_HOME}/logs
Si vous souhaitez placer le fichier wrapper.log à un autre emplacement, vous devrez éditer le fichier wrapper.conf
et modifier la propriété wrapper.logfile pour refléter le nouvel emplacement.
La ligne de commande Java
La ligne de commande Java d'un jar exécutable est assez simple.
Dans le cas de JBoss, il suffit d'aller dans le répertoire JBoss et d'exécuter :
Afin d'utiliser la ligne de commande Java ci-dessus avec le Wrapper, nous devons décomposer les composants de la ligne de commande dans un fichier de configuration.
Ouvrir le fichier wrapper.conf dans un éditeur et apporter les modifications ci-dessous.
NOTE
Pour toutes les propriétés mentionnées ci-dessous, des liens vers leurs descriptions sont fournis.
Veuillez prendre le temps de consulter les descriptions de toutes les propriétés qui sont modifiées.
Dans de nombreux cas, des détails supplémentaires sur leur utilisation ne sont pas mentionnés ici.
Exécutable Java
Tout d'abord, extraire l'exécutable Java et assigner le chemin d'emplacement à la
propriété wrapper.java.command :
wrapper.java.command=java
Jar du Wrapper
Le Wrapper exige que son wrapper.jar soit spécifié :
wrapper.jarfile=/usr/lib/jboss/lib/wrapper.jar
AVERTISSEMENT
La propriété wrapper.jarfile a été introduite dans la version 3.5.55.
Lors de l'utilisation de versions antérieures du Wrapper, il est nécessaire d'inclure wrapper.jar dans le classpath :
Ensuite, les indices des éléments de classpath suivants doivent être ajustés afin que la propriété wrapper.java.classpath.1 ne soit pas répétée.
Classpath
Vient ensuite le classpath, qui est configuré à l'aide des
propriétés wrapper.java.classpath.<n>.
Java ne permet pas réellement de spécifier un classpath lors de l'exécution avec le paramètre -jar
mais cette intégration avec le Wrapper fonctionne un peu différemment.
Lors de l'utilisation du Wrapper et de la classe d'aide WrapperJarApp, Java n'exécute pas le jar directement.
Il est nécessaire de spécifier la classe d'aide comme classe principale de l'application.
La classe principale exécutée par Java au lancement est spécifiée à l'aide de la
propriété wrapper.java.mainclass comme suit :
Les paramètres de l'application sont définis à l'aide des
propriétés wrapper.app.parameter.<n>.
Dans ce cas, la ligne de commande pour lancer JBoss nécessite certains paramètres d'application.
Il est nécessaire d'indiquer à la classe d'aide WrapperJarApp quel jar exécuter.
Cela se fait comme suit :
Les paramètres Java supplémentaires sont définis à l'aide des
propriétés wrapper.java.additional.<n>.
Certains paramètres doivent être définis pour la JVM afin de démarrer JBoss correctement.
Afin d'utiliser le Wrapper, une propriété supplémentaire doit être définie.
Le Wrapper utilise une bibliothèque native pour contrôler les interactions avec le système.
Ce fichier de bibliothèque libwrapper.so doit être spécifié
dans le chemin des bibliothèques fourni à la JVM.
JBoss n'a pas de bibliothèques natives propres, mais s'il en avait, les répertoires où elles se trouvent devraient également être spécifiés.
Le chemin des bibliothèques est défini à l'aide des
propriétés wrapper.java.library.path.<n>.
wrapper.java.library.path.1=/usr/lib/jboss/lib
Rassembler le tout
En rassemblant le tout, nous obtenons ce qui suit :
Notez que, bien que ces configurations fonctionnent correctement sur notre machine de test,
elles dépendent fortement de la structure des répertoires et de la plateforme.
En tirant parti du fait que le Wrapper définit toujours le répertoire de travail
à l'emplacement du fichier wrapper.exe et en utilisant une seule variable d'environnement,
nous pouvons modifier les propriétés ci-dessus afin qu'elles soient complètement indépendantes de la plateforme et de la machine :
JBoss peut maintenant être exécuté simplement en lançant le script bin/myJBoss console.
En raison de la façon dont le Wrapper définit son répertoire courant, il n'est pas nécessaire
d'exécuter ce script depuis le répertoire bin.
Comme vous le verrez si vous omettez une commande, le script livré avec le Wrapper est un script daemon assez standard.
Il accepte les commandes console, start, stop, restart et dump.
Les commandes start, stop et restart
sont communes à la plupart des scripts daemon et sont utilisées pour contrôler le Wrapper et son application en tant que processus daemon.
La commande status peut être utilisée pour savoir si le Wrapper est actuellement en cours d'exécution.
La commande console lancera le Wrapper dans le shell courant,
ce qui permet d'arrêter l'application avec CTRL-C.
La dernière commande, dump, enverra un signal « kill -3 »
au Wrapper, ce qui amènera sa JVM à effectuer un dump complet des threads.
Félicitations. Votre application devrait maintenant être opérationnelle.
Si vous rencontrez des problèmes, veuillez consulter la section Dépannage
pour obtenir de l'aide afin d'identifier le problème.