Lorsque le Wrapper est lancé, il s'assure avec soin que le répertoire de travail se trouve dans un état connu et constant. Cela permet de garantir qu'il n'y aura pas de problèmes liés aux chemins causés par un utilisateur lançant le Wrapper depuis divers emplacements.

Sur toutes les plates-formes, le Wrapper force son répertoire de travail vers le répertoire où se trouve son binaire immédiatement au démarrage. Ceci est essentiel, car les processus sont lancés par leur système d'exploitation parent avec le même répertoire de travail que leur processus parent.

Cela signifie que le répertoire de travail serait différent dans chacune des trois commandes suivantes : bin\wrapper.exe, .\wrapper.exe, ..\bin\wrapper.exe. Lors de l'exécution en tant que service Windows, le répertoire de travail serait défini sur le répertoire Windows system32.

Cette incohérence du répertoire de travail rendrait impossible l'utilisation de chemins relatifs dans le fichier de configuration du Wrapper.

wrapper.logfile=C:\Program Files\myapp\logs\wrapper.log

Remarquez qu'un chemin absolu doit être défini vers un emplacement unique pour chaque installation. Cela signifie qu'un programme d'installation serait nécessaire pour l'application, et que celui-ci devrait modifier les fichiers de configuration. Si l'utilisateur déplace un jour l'application sur son disque dur, la configuration serait alors cassée et ne fonctionnerait plus.

wrapper.logfile=../logs/wrapper.log

Les chemins relatifs, en revanche, sont très utiles. Ils fonctionneront quel que soit l'emplacement d'installation de l'application. Les chemins peuvent également être définis à l'aide de barres obliques afin que le même fichier de configuration fonctionne à la fois sur les plates-formes Windows et UNIX sans modification. La configuration fonctionnera également correctement même si l'utilisateur déplace l'application entière vers un autre emplacement ou un autre lecteur.

Flexibilité du répertoire de travail « wrapper.working.dir » :

Il arrive cependant que le fait d'avoir le répertoire de travail défini à l'emplacement du binaire du Wrapper rende impossible l'exécution propre de certaines applications. Un exemple est une application qui s'attend à ce que le répertoire de travail soit à la racine du système de fichiers. La seule façon d'exécuter une telle application sous le Wrapper serait de placer le binaire et les scripts du Wrapper dans le répertoire racine. Ce n'est pas quelque chose que la plupart des administrateurs système souhaiteraient faire.

Pour permettre de tels cas exceptionnels, la propriété wrapper.working.dir a été ajoutée. Il est très important de comprendre exactement comment cette propriété fonctionne afin d'éviter les problèmes.

1. Chemin relatif vers le binaire du Wrapper :

La propriété wrapper.working.dir peut être spécifiée soit dans le fichier de configuration « wrapper.conf » soit comme paramètre du binaire du Wrapper. Cependant, la propriété ne prend effet qu'APRÈS que le fichier de configuration du Wrapper a été entièrement chargé. Cela signifie que l'emplacement du fichier wrapper.conf et de tout fichier d'inclusion (style en cascade) qui y est référencé doit toujours être indiqué à l'aide d'emplacements relatifs au binaire du Wrapper. Ceci est nécessaire pour garantir que le fichier de configuration puisse être chargé de manière fiable.

Toutes les variables d'environnement référencées dans le fichier de configuration seront remplacées au fur et à mesure que les lignes individuelles du fichier de configuration sont chargées. Ceci est un point important si elles sont utilisées pour construire des valeurs de chemin dans les propriétés.

2. Chemin relatif vers un nouveau répertoire de travail :

Tous les chemins définis dans les AUTRES propriétés spécifiées soit depuis la ligne de commande soit dans le fichier wrapper.conf seront alors relatifs à l'emplacement spécifié par la propriété wrapper.working.dir.

Vous êtes perdu ? Quelques exemples s'imposent.

Windows sera utilisé comme exemple, mais les problèmes sont les mêmes pour les plates-formes Linux/UNIX.

C:\myapp\
    bin\
        wrapper.exe
    conf\
        wrapper.conf
        include.conf
    lib\
        wrapper.dll
        wrapper.jar
        myapp.jar
    logs\
        wrapper.log

Sans utiliser la propriété wrapper.working.dir, le répertoire de travail se trouvera dans le répertoire C:\myapp\bin (l'emplacement du binaire du Wrapper). Le Wrapper pourrait être lancé à l'aide de la commande suivante.

bin\wrapper.exe -c ../conf/wrapper.conf

Les chemins dans le fichier wrapper.conf seraient configurés comme suit. (Notez qu'il ne s'agit pas d'un fichier de configuration complet.) :

@include ../conf/include.conf
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/myapp.jar
wrapper.java.library.path.1=../lib
wrapper.pidfile=./wrapper.pid
wrapper.java.pidfile=./java.pid
wrapper.logfile=../logs/wrapper.log

Notez que tous les chemins sont relatifs à l'emplacement du binaire du Wrapper « wrapper.exe » (C:\myapp\bin).

La même structure de répertoires que dans l'exemple précédent sera réutilisée.

C:\myapp\
    bin\
        wrapper.exe
    conf\
        wrapper.conf
        include.conf
    lib\
        wrapper.dll
        wrapper.jar
        myapp.jar
    logs\
        wrapper.log

Cette fois, la propriété wrapper.working.dir sera définie sur le parent du répertoire bin dans lequel se trouve le fichier wrapper.exe. Il s'agit d'un emplacement communément appelé répertoire HOME de l'application. C:\myapp dans ce cas.

La propriété wrapper.working.dir peut être spécifiée soit sur la ligne de commande utilisée pour lancer le Wrapper, soit dans le fichier wrapper.conf. Dans les deux cas, le répertoire spécifié peut être absolu ou relatif. Dans le cas d'un répertoire relatif, le répertoire sera relatif à l'emplacement du binaire du Wrapper. (Résultat : = C:\myapp)

wrapper.working.dir=../

Cet exemple spécifie le nouveau répertoire de travail en utilisant la propriété wrapper.working.dir dans le fichier wrapper.conf. Dans ce cas, la commande utilisée pour lancer le Wrapper reste inchangée, ce qui signifie que les fichiers batch et les scripts fournis avec le Wrapper peuvent être utilisés sans aucune modification.

bin\wrapper.exe -c ../conf/wrapper.conf

Lorsque le Wrapper est lancé, il définit immédiatement son propre répertoire de travail à l'emplacement du binaire du Wrapper (C:\myapp\bin). Il charge ensuite le fichier de configuration « wrapper.conf » et tout fichier d'inclusion (style en cascade) en utilisant ce répertoire de travail. Une fois la configuration chargée, le répertoire de travail sera modifié vers le nouvel emplacement spécifié par la propriété wrapper.working.dir (C:\myapp\). Tous les chemins ultérieurs, y compris le lancement de la JVM, seront effectués en utilisant ce nouveau répertoire de travail.

Pour cet exemple, le fragment de wrapper.conf utilisé ci-dessus sera modifié comme suit :

wrapper.working.dir=../
@include ../conf/include.conf
wrapper.java.classpath.1=lib/wrapper.jar
wrapper.java.classpath.2=lib/myapp.jar
wrapper.java.library.path.1=lib
wrapper.pidfile=bin/wrapper.pid
wrapper.java.pidfile=bin/java.pid
wrapper.logfile=logs/wrapper.log

Remarquez que l'emplacement du fichier d'inclusion (style en cascade) et de la propriété wrapper.working.dir sont tous deux relatifs à l'emplacement du binaire du Wrapper (C:\myapp\bin), mais que tous les autres chemins sont désormais relatifs au nouveau répertoire de travail (C:\myapp\).

L'emplacement de la propriété wrapper.working.dir dans le fichier wrapper.conf n'est pas important, car elle n'est pas appliquée avant que l'ensemble du fichier de configuration n'ait été analysé.

Des problèmes ?

Si vous rencontrez des problèmes liés à la configuration du Wrapper, la première chose à faire est d'activer la propriété wrapper.debug et de relancer l'application. Assurez-vous que l'application peut être exécutée en tant qu'application console avant d'essayer de l'exécuter en tant que service Windows ou processus démon UNIX.

Certaines applications ont besoin de pouvoir définir leur répertoire de travail à l'emplacement depuis lequel l'application a été lancée. La plupart des serveurs souhaitent s'exécuter dans un emplacement connu, tandis que la plupart des applications en ligne de commande ont besoin de connaître le contexte de leur exécution. Un exemple simple est la commande mkdir. Elle a besoin de savoir depuis où la commande est exécutée afin de décider où créer le nouveau répertoire.

À partir de la version 3.5.6 du Wrapper, la variable d'environnement WRAPPER_INIT_DIR conserve cet emplacement.

Dans la plupart de ces cas, vous souhaiterez simplement transmettre cette valeur à votre application, tout en vous assurant que votre application et tous ses fichiers journaux sont écrits dans un emplacement connu. Cela peut se faire en transmettant l'emplacement à la JVM dans une propriété système.

wrapper.java.additional.1=-myinit.working.dir=%WRAPPER_INIT_DIR%

String s = System.getProperty("myinit.working.dir");
File f = new File(s, "test1/myout.txt");

Si, toutefois, vous souhaitez vraiment définir le répertoire de travail du Wrapper et de son application sur l'emplacement actuel, cela peut se faire en définissant le répertoire de travail sur l'emplacement du répertoire initial. Sachez que vous voudrez très probablement définir l'emplacement de tout fichier journal, fichier PID, etc. avec un chemin absolu afin de toujours pouvoir les trouver. Le fichier de configuration du Wrapper sera toujours chargé relativement à l'emplacement du binaire du Wrapper.

wrapper.working.dir=%WRAPPER_INIT_DIR%

Les variables d'environnement sont décrites plus en détail sur la page Travailler avec les variables d'environnement. Nous aborderons ici quelques points directement liés aux répertoires de travail.

Le Wrapper définit 2 variables d'environnement directement associées au répertoire de travail.

• La variable WRAPPER_BIN_DIR (Depuis la ver. 3.3.0) sera toujours définie à l'emplacement du binaire du Wrapper au démarrage. Elle peut être utilisée comme point de référence plus loin dans le fichier de configuration, même si le répertoire de travail est modifié.

• La variable WRAPPER_WORKING_DIR (Depuis la ver. 3.3.0) est un peu déroutante et n'est pas vraiment utile lorsqu'elle est référencée depuis le fichier de configuration du Wrapper. Elle est toujours définie sur le répertoire de travail actuel, et sera définie sur la valeur spécifiée avec la propriété wrapper.working.dir. Mais toute référence à la variable dans le fichier de configuration sera remplacée lors du chargement du fichier de configuration. Rappelez-vous qu'à ce moment-là, le répertoire de travail est encore défini à l'emplacement du binaire du Wrapper. Cette variable d'environnement n'est utile qu'au sein de la JVM et de ses processus enfants lorsqu'ils demandent la variable d'environnement au niveau du système.

Il est également possible pour les utilisateurs de définir leurs propres variables d'environnement dans le fichier de configuration du Wrapper. Celles-ci sont définies dans l'environnement au fur et à mesure de leur analyse. Grâce à cela, vous pouvez faire des choses astucieuses. Dans l'exemple suivant, nous créerons une variable MYAPP_HOME puis non seulement définirons le répertoire de travail, mais l'utiliserons également dans d'autres propriétés. Notez que la variable d'environnement peut également être utilisée lors du chargement des fichiers d'inclusion (style en cascade).

set.MYAPP_HOME=c:\myapp\
wrapper.working.dir=%MYAPP_HOME%
@include %MYAPP_HOME%/conf/include.conf
wrapper.java.classpath.1=%MYAPP_HOME%/lib/wrapper.jar
wrapper.java.classpath.2=%MYAPP_HOME%/lib/myapp.jar
wrapper.java.library.path.1=%MYAPP_HOME%/lib
wrapper.pidfile=%MYAPP_HOME%/bin/wrapper.pid
wrapper.java.pidfile=%MYAPP_HOME%/bin/java.pid
wrapper.logfile=%MYAPP_HOME%/logs/wrapper.log

Cette méthode peut être utilisée si wrapper.exe doit être placé dans un emplacement en dehors de la structure de répertoires de l'application. S'il s'agit par exemple d'une commande système.