Wenn der Wrapper gestartet wird, überprüft er sehr gewissenhaft, ob das Arbeitsverzeichnis sich in einem bekannten und gleichbleibenden Zustand befindet. Dies hilft, sicherzustellen, dass es keine pfadbezogenen Probleme bei durch einen User bewirkten Starten des Wrappers von verschiedenen Orten aus gibt.

Auf allen Plattformen legt der Wrapper sein Arbeitsverzeichnis auf das Verzeichnis fest, in dem seine Programmdatei sofort nach dem Starten gespeichert wird. Dies ist sehr wichtig, weil Prozesse von ihrem zugehörigen Betriebssystem mit demselben Arbeitsverzeichnis wie ihr Elternprozess gestartet werden.

Dies bedeutet, dass das Arbeitsverzeichnis in allen drei der folgenden Befehlen verscheiden sein würde: bin\wrapper.exe, .\wrapper.exe, ..\bin\wrapper.exe. Beim Ausführen als ein Windows Dienst würde das Arbeitsverzeichnis auf das Windows system32-Verzeichnis festgelegt werden.

Diese Unstimmigkeit bezüglich des Arbeitsverzeichnisses würde es unmöglich machen, innerhalb der Konfigurationsdatei des Wrappers irgendwelche relative Pfade zu nutzen.

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

Beachten Sie bitte, dass ein absoluter Pfad auf einen Speicherort festgelegt werden muss, der für jede Installation einheitlich ist. Dies bedeutet, dass für die Anwendung ein Installationsprogramm benötigt würde, und dass das Installationsprogramm die Konfigurationsdateien öffnen und verändern müsste. Wenn der User jemals die Anwendung auf seiner Festplatte verschieben würde, dann würde die Konfiguration nicht länger stimmen.

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

Andererseits sind relative Pfadangaben sehr nützlich. Sie funktionieren ganz unabhängig davon, wo die Anwendung installiert wurde. Die Pfade können auch unter Verwendung von Schrägstrichen definiert werden; so wird die exakt gleiche Konfigurationsdatei unter Windows- und UNIX-Plattformen ohne Änderung gleich funktionieren. Die Konfiguration funktioniert auch korrekt, selbst wenn der User die komplette Anwendung an einen anderen Speicherort oder Festplatte verschieben würde.

Flexibles Arbeitsverzeichnis "wrapper.working.dir":

Es mag aber Fälle geben, in denen durch das Setzen des Arbeitsverzeichnisses auf den Speicherort der Wrapper-Programmdatei es unmöglich wird, einige Anwendungen korrekt auszuführen. Ein Beispiel ist eine Anwendung, welches das Arbeitsverzeichnis im Hauptverzeichnis Ihres Dateisystems erwartet. Der einzige Weg solch eine Anwendung via des Wrappers auszuführen, wäre es, die Wrapper-Programmdatei und -Skripte in das Wurzelverzeichnis zu speichern. Das ist etwas, was die meisten Systemadministratoren meist nicht tun möchten.

Um solche außergewöhnliche Fälle zu ermöglichen, wurde die wrapper.working.dir-Eigenschaft hinzugefügt. Es ist sehr wichtig, genau zu verstehen, wie diese Eigenschaft funktioniert, um Probleme zu vermeiden.

1.Relativer Pfad zur Wrapper-Programmdatei:

Der wrapper.working.dir Eigenschaft kann entweder in der Konfigurationsdatei "wrapper.conf" spezifiziert werden oder als ein Parameter der Wrapper-Programmdatei. Jedoch wird diese Eigenschaft nicht wirksam bis zum Zeitpunkt, nachdem die Konfigurationsdatei des Wrappers komplett geladen wurde. Dies bedeutet, dass der Speicherort der wrapper.conf-Datei und alle hinzugefügten Dateien (kaskadierender Stil), auf die darin verwiesen wird, müssen stets unter Nutzung von relativen Speicherpfaden - relativ zur Wrapper-Programmdatei - verwiesen werden. Dies ist notwendig, um sicherzustellen, dass die Konfigurationsdatei korrekt geladen werden kann.

Alle Umgebungsvariablen, auf die in der Konfigurationsdatei verwiesen wird, werden zu dem Zeitpunkt, zu dem die einzelnen Zeilen der Konfigurationsdatei geladen werden, ersetzt. Dies ist ein wichtiger Punkt, wenn sie genutzt werden, um Pfadwerte innerhalb von Eigenschaften zu erstellen.

2.Relativer Pfad zu einem neuen Arbeitsverzeichnis:

Alle Pfade, die in ANDEREN Eigenschaften definiert sind, spezifiziert entweder von der Befehlszeile oder innerhalb der wrapper.conf-Datei werden dann relativ zu dem Speicherpfad sein, der durch die wrapper.working.dir-Eigenschaft spezifiziert ist.

Noch nicht klar? Ein oder zwei Beispiele folgen.

Windows wird als Beispiel genutzt, aber die Problemfälle sind die Gleichen unter Linux/UNIX-Plattformen.

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

Ohne den Einsatz der wrapper.working.dir-Eigenschaft, befindet sich das Arbeitsverzeichnis im C:\myapp\bin-Verzeichnis (dem Speicherort der Wrapper-Programmdatei). Der Wrapper könnte unter Nutzung des folgenden Befehls gestartet werden.

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

Pfadangaben in der wrapper.conf-Datei würden wie folgt konfiguriert werden. (Beachten Sie bitte, dass dies nicht eine komplette Konfigurationsdatei ist.):

#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

Beachten Sie bitte, dass alle Pfade relativ zu dem Speicherort der Wrapper-Programmdatei "wrapper.exe"-Datei (C:\myapp\bin) sind.

Die gleiche Verzeichnisstruktur, die im vorherigen Beispiel genutzt wurde, wird wieder benutzt.

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

Dieses Mal wird die wrapper.working.dir Eigenschaft als übergeordnetes Verzeichnis des bin-Verzeichnisses festgelegt werden, in dem sich die wrapper.exe-Datei befindet. Dies ist ein Speicherort, auf den gewöhnlich als Speicherort des HOME-Verzeichnisses der Anwendung verwiesen wird. C:\myapp in diesem Fall.

Die wrapper.working.dir Eigenschaft kann entweder von der Befehlszeile, genutzt um den Wrapper zu starten, spezifiziert werden oder innerhalb der wrapper.conf-Datei. In beiden Fällen kann das spezifizierte Verzeichnis absolut oder relativ sein. Im Falle eines relativen Verzeichnis wird das Verzeichnis relativ zum Speicherort der Wrapper-Programmdatei sein. (Als Ergebnis: = C:\myapp)

wrapper.working.dir=../

Dieses Beispiel spezifiziert das neue Arbeitsverzeichnis unter Nutzung der wrapper.working.dir-Eigenschaft innerhalb der wrapper.conf-Datei. So in diesem Fall ist der Befehl, um den Wrapper zu starten, unverändert, was bedeutet, dass die Batch-Dateien und Skripts, die mit dem Wrapper ausgeliefert werden, ohne Abänderung eingesetzt werden können.

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

Wenn der Wrapper gestartet wird, legt er sofort sein eigenes Arbeitsverzeichnis auf den Speicherort der Wrapper-Programmdatei fest (C:\myapp\bin). Dann lädt er die Konfigurationsdatei "wrapper.conf"-Datei und alle eingefügten Dateien (kaskadierender Stil) unter Nutzung des Arbeitsverzeichnisses. Nachdem die Konfiguration geladen wurde, wird das Arbeitsverzeichnis auf den neuen Speicherort geändert, der durch die wrapper.working.dir-Eigenschaft (C:\myapp\) spezifiziert wurde. Alle zukünftigen Pfade, inklusive das Starten der JVM, werden unter Nutzung diese neuen Arbeitsverzeichnisses getan.

Für dieses Beispiel, wird der oben genannte wrapper.conf-Teil wie folgt verändert werden:

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

Bitte beachten Sie, dass der Speicherort von Dateien hinzufügen (kaskadierender Stil) und wrapper.working.dir-Eigenschaft beide relativ zum Wrapper-Programmdatei-Speicherort sind (C:\myapp\bin), aber alle anderen Pfade relativ zu dem neuen Arbeitsverzeichnis sind (C:\myapp\).

Der Speicherort von wrapper.working.dir-Eigenschaft innerhalb der wrapper.conf-Datei ist nicht wichtig, da sie nicht angewendet wird bis wenn die komplette Konfigurationsdatei geparst wird.

Probleme?

Wenn Sie mit Problemen bezüglich der Konfiguration des Wrappers konfrontiert sind, ist das Erste, was Sie tun sollten, die wrapper.debug Eigenschaft zu aktivieren und die Anwendung erneut auszuführen. Stellen Sie bitte sicher, dass die Anwendung als Konsolenanwendung ausgeführt werden kann, bevor sie versuchen, diese als einen Windows Dienst oder UNIX-Daemonprozess auszuführen.

Einige Anwendungen benötigen die Fähigkeit, ihr Arbeitsverzeichnis auf den Speicherort festzulegen, von den aus die Anwendung ausgeführt wurde. Die meisten Server wollen in einem bekannten Speicherort ausgeführt werden, jedoch müssen die meisten Befehlszeilenanwendungen darüber informiert werden, in welchem Kontext sie ausgeführt werden. Ein einfaches Beispiel ist der mkdir-Befehl. Er muß darüber Bescheid wissen, von wo aus der Befehl ausgeführt wurde, um in der Lage zu sein, zu entscheiden, wo das neue Verzeichnis erstellt werden soll.

Ab der Wrapper-Version 3.5.6, beobacht die WRAPPER_INIT_DIR Umgebungsvariable diesen Speicherort.

In den meisten solchen Fällen möchten Sie einfach diesen Wert Ihrer Anwendung übergeben, aber auch gleichzeitig sicherstellen, dass Ihre Anwendung und alle ihrer Logdateien an einem bekannten Speicherort gespeichert werden. Dies kann durch Übergabe des Speicherorts zur JVM in einer Systemeigenschaft getan werden.

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

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

Wenn Sie jedoch den Wrapper und sein Anwendungsverzeichnis auf den aktuellen Verzeichnispfad festlegen möchten, kann dies getan werden, indem Sie das Arbeitssverzeichnis auf den Startverzeichnispfad festlegen. Seien Sie sich bitte bewusst, dass dies sehr wahrscheinlich den Speicherpfad jeder Logdatei, PID-Datei etc. auf einen absoluten Verzeichnispfad festlegen wird, um sicherzustellen, dass sie stets gefunden werden können. Die Konfigurationsdatei des Wrappers wird stets relativ zum Speicherpfad der Wrapper-Programmdatei geladen werden.

wrapper.working.dir=%WRAPPER_INIT_DIR%

Umgebungsvariablen werden ausführlicher auf der Working With Environment Variables-Seite beschrieben. Wir behandeln ein paar der Probleme, die mit Arbeitsverzeichnissen zu tun haben, hier.

Der Wrapper setzt 2 Umgebungsvariablen, die direkt mit dem Arbeitsverzeichnis in Zusammenhang stehen.

• Die WRAPPER_BIN_DIRVariable (Seit der Ver. 3.3.0) wird beim Starten stets auf den Speicherpfad der Wrapper-Programmdatei festgelegt. Es kann später als ein Referenzpunkt in der Konfigurationsdatei genutzt werden; auch im Fall, dass das Arbeitsverzeichnis verändert wurde.

• Die WRAPPER_WORKING_DIR Variable (Seit Ver. 3.3.0) ist ein wenig verwirrend und nicht wirklich nützlich, wenn auf sie von innerhalb der Wrapper-Konfigurationsdatei verwiesen wird. Es wird stets auf das gegenwärtige Arbeitssverzeichnis festgelegt, und wird auf den Wert festgelegt, der in der Eigenschaft wrapper.working.dir spezifiziert ist. Aber jeder Verweis zu einer Variable in der Konfigurationsdatei wird ersetzt werden, wenn die Konfigurationsdatei geladen wird. Bitte erinnern Sie sich in diesem Moment daran, dass das Arbeitssverzeichnis immer noch auf den Speicherpfad der Wrapper-Programmdatei festgelegt ist. Diese Umgebungsvariable ist nur innerhalb der JVM und ihrer Kindprozesse sinnvoll, wenn sie die Umgebungsvariable auf Systemebene abfragen.

It is für User auch möglich innerhalb der Wrapper-Konfigurationsdatei ihre eigenen Umgebungsvariablen zu definieren. Dies werden im Moment, wenn sie geparst werden, in ihrer Umgebung festgelegt. Aufgrunddessen können Sie ausgefallene Dinge damit tun. Im folgenden Beispiel erstellen wir die MYAPP_HOME-Variable und legen dann nicht nur das Arbeitssverzeichnis fest, sondern machen davon auch in anderen Eigenschaften Gebrauch. Beachten Sie, dass die Umgebungsvariable auch genutzt werden kann, wenn sie via include files (cascading style) geladen wird.

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

Diese Methode kann genutzt werden, wenn die wrapper.exe in einem Speicherpfad außerhalb der Anwendungsverzeichnisstruktur. Wenn es sich z.B. um einen systemweiten Befehl handelt.