wrapper.working.dir

Kompatibel :3.1.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

WARNING

Bitte ändern Sie NICHT irgendeinen dieser Parameter, solange Sie nicht diese Eigenschaftsbeschreibung gelesen haben. Inkorrekte Einstellungen können zur Folge haben, dass der Wrapper nicht wie erwartet funktioniert. Sie können sich durch Lesen dieser Seite, BEVOR Sie beginnen mit dieser Eigenschaft zu spielen, viel Zeit sparen.

Übersicht wie Arbeitsverzeichnis funktioniert

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.

Absoluter Pfad:
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.

Relative Pfadangaben:
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.

Beispiel ohne das Festlegen von wrapper.working.dir

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

Einfache Verzeichnisstruktur:
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.

Befehlsbeispiel: (Starten des Wrappers)
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.):

Beispiel: (Konfigurationsdatei)
#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.

Beispiel für das Festlegen von wrapper.working.dir

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

Gleiche Verzeichnisstruktur:
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)

Beispiel: ("wrapper.working.dir" Eigenschaft) = 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.

Befehlsbeispiel: (Starten des Wrappers)
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:

Beispiel: (Konfigurationsdatei)
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.

Beispiel Setzen von wrapper.working.dir als Startverzeichnis

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.

Beispiel der Wrapper-Konfigurationsdatei:
wrapper.java.additional.1=-myinit.working.dir="%WRAPPER_INIT_DIR%"
wrapper.java.additional.1.stripquotes=TRUE
Beispiel von Java-Code:
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.

Beispiel der "wrapper.working.dir" Eigenschaft:
wrapper.working.dir=%WRAPPER_INIT_DIR%

Beispiel unter Nutzung von Umgebungsvariablen

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.

Beispiel der Konfigurationsdatei:
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.

NOTE

Änderungen an diesem Eigenschaftswert haben keine Auswirkung auf den Wrapper, wenn die Konfiguration neu geladen wird. Der Wrapper muß neu gestartet werden, damit die Änderungen wirksam werden.

Verweis: Bibliothek