Wrapperを起動するとき、作業ディレクトリーがしっかり指定され、確実に一定の状態であるように確認してください。 こうすることで、ユーザーが様々な場所からWrapperを起動することで引き起こされる問題、 それに関連するパストラブルは一切ないと確信できるので、大いに役立ちます。

全てのプラットフォーム上において、Wrapperは、スタートアップ時に即座に、 作業ディレクトリーをWrapperバイナリが配置されているディレクトリーへ強制設定します。 これは、その親プロセスと同じ作業ディレクトリーを使い、親OSによってプロセスが起動されるため、重要なことです。

つまり、これは、次の３つのコマンドで作業ディレクトリーが異なります： 「bin\wrapper.exe」、 「.\wrapper.exe」、 「..\bin\wrapper.exe」。 Windowsサービスとして動作するとき、作業ディレクトリーは、 Windows 「system32」ディレクトリーへ設定されることでしょう。

この作業ディレクトリーの矛盾により、 Wrapperのコンフィギュレーションファイル内で、 相対パスの利用が不可能になります。

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

各インストールごとに絶対パスを使って固有の配置場所へ配置するまでの手法過程について注目してみましょう。 つまり、これでは、アプリケーション用のインストーラーを必要とし、 そのインストーラーが深入りしてコンフィギュレーションファイルの設定をする必要があります。 もしユーザーが、ハードドライブ上でアプリケーションのインストール場所を動かしでもしたら、 それでコンフィギュレーションファイルに矛盾が生じ、もはや動作しなくなります。

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

その一方で、相対パスは、とても便利です。 アプリケーションをどこにインストールしようが、そのパスは有効であり動作します。 また、パスは、フォワードスラッシュを利用して定義することができるため、 WindowsでもUNIXでも、どちらのプラットフォームでも 設定を変更する必要はなく、まったく同じコンフィギュレーションファイルを利用することができます。 ユーザーがアプリケーションのインストール場所を丸ごと他の場所へ移動させたとしても、 そのコンフィギュレーションは正しく動作するでしょう。

柔軟な工夫「wrapper.working.dir」：

しかしながら、一部のアプリケーションでは、 作業ディレクトリーをWrapperバイナリの配置場所に設定すると、キレイに動作しない可能性もあります。 １つ例をあげると、 作業ディレクトリーがファイルシステムのルートにあることを期待しているアプリケーションの場合です。 Wrapper下で、そのようなアプリケーションを動作させる唯一の方法は、 ルートディレクトリーに、Wrapperバイナリ や スクリプトを置くと良いでしょう。 ほとんどのシステム管理者が避けたがるような事ですが。

そのような特殊なケースにも対応するために、 ［wrapper.working.dir］プロパティを設けました。 問題を回避するために、このプロパティの動作の仕方について、正確に理解することは非常に重要です。

1.Wrapperバイナリからの相対パス：

コンフィギュレーションファイル 「wrapper.conf」の中で、 あるいは、Wrapperバイナリへのパラメータとして、 ［wrapper.working.dir］プロパティを指定することができます。 しかしながら、そのコンフィギュレーションファイルが完全に読み込まれるまで、このプロパティは有効になりません。 つまり、これは、 「wrapper.conf」ファイルの配置場所や、 そこで参照されているインクルードファイル（カスケード形式）の配置場所が、 どれもWrapperバイナリからの相対パスで参照されていなければなりません。 確実にコンフィギュレーションファイルがロード（読み込み）されるよう設定する必要があります。

コンフィギュレーションファイルの各行がロード（読み込み）され、 コンフィギュレーションファイル内で参照されている 環境変数が置き換えられます。 これは、プロパティ内でパス値の構成に利用されている場合には、重要なポイントです。

2.新しい作業ディレクトリーからの相対パス：

コマンドラインから、あるいは、 「wrapper.conf」 ファイル内部で指定された、他のプロパティで定義されたパスは、 ［wrapper.working.dir］プロパティで指定された場所からの相対パスです。

まだ混乱してる？では、順番に例をあげて確認していきましょう。

１つの例としてWindowsを例にあげますが、この問題はLinux/UNIXプラットフォームであっても全て同様です。

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

［wrapper.working.dir］プロパティを使わずに、 作業ディレクトリーが 「C:\myapp\bin」ディレクトリー（Wrapperバイナリのある場所）に配置されます。 下記のコマンドを使って、Wrapperを起動できます。

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

「wrapper.conf」ファイル内で指定するパスは、 以下のように明記されているはずです。 （注意：これは抜粋のため、完全なコンフィギュレーションファイルではありません）：

#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

全てのパスが、Wrapperバイナリ「wrapper.exe」ファイルの配置場所 （C:\myapp\bin）からの 相対パスであることに注目してください。

前述の、同じディレクトリー構造と想定します。

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

今回、［wrapper.working.dir］プロパティは、 「wrapper.exe」ファイルがある 「bin」 ディレクトリーの親ディレクトリーに設定します。 これは、アプリケーションのHOMEディレクトリーとして、よく利用される配置場所です。 今回のケースでは、「C:\myapp」です。

［wrapper.working.dir］プロパティは、 Wrapper起動時に使うコマンドラインから、 あるいは、 「wrapper.conf」ファイル内部で、 設定することができます。 どちらのケースでも、ディレクトリーの指定は、絶対パスか相対パスで書かれていますが、 相対パスで指定されたディレクトリーは、Wrapperバイナリの配置場所からの相対的な位置になります。 （結果として＝「C:\myapp」）

wrapper.working.dir=../

この例では、「wrapper.conf」ファイル内部で、 ［wrapper.working.dir］プロパティを使って、 新しい作業ディレクトリーを指定しています。 従って、このケースの場合、Wrapper起動に利用しているコマンドには変更がありません。 つまり、Wrapperに同梱して提供しているバッチファイル や スクリプトは、何も変更せずに、そのまま利用することができます。

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

Wrapperが起動されると、 Wrapperバイナリが配置されているディレクトリー(C:\myapp\bin)を、 作業ディレクトリーとして即座に設定します。 その後、その作業ディレクトリーを使って、 コンフィギュレーションファイル「wrapper.conf」 ファイルやインクルードファイル（カスケード形式）をロード（読み込み）します。 コンフィギュレーションファイルがロード（読み込み）された後、 ［wrapper.working.dir］プロパティで指定された 新しい配置場所 (C:\myapp\)を作業ディレクトリーとして設定します。 その後からは、JVM起動を含む全てのパスは、その新しい作業ディレクトリーが使われます。

前述の「wrapper.conf」 の部分は、この例では、以下のように変更します：

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

インクルードファイル（カスケード形式）の配置場所や、 ［wrapper.working.dir］プロパティは、両方とも、 Wrapperバイナリの配置場所 (C:\myapp\bin)からの相対パスであることに注目してください。 しかし、全ての他のパスは、今、新しい作業ディレクトリー(C:\myapp\)からの相対パスになっています。

コンフィギュレーションファイル全体が読み込まれて解釈されるまで設定が有効にならないため、 「wrapper.conf」ファイルの中にある ［wrapper.working.dir］プロパティの記述場所は重要ではありません。

問題？：

もしWrapperの設定に関する問題に遭遇した場合には、まず最初にするべきことは、 ［wrapper.debug］プロパティを 有効にして、アプリケーションを再始動させることです。 アプリケーションをWindowsサービスとして、あるいは、デーモンプロセスとして動かしてみる前に、 コンソールアプリケーションとして動作するか、確認してください。

一部のアプリケーションでは、アプリケーションが動作している場所を 自分の作業ディレクトリーとして設定する必要がある場合もあります。 ほとんどサーバーは既知の場所で動作させるものですが、 ほとんどコマンドラインアプリケーションは、どこで動作しているのか状態を知る必要があります。 例えば、１つシンプルな例は、「mkdir」コマンドです。 そのコマンドで新しいディレクトリーを作成するために、作成するべき場所を見極める必要があり、 そのコマンドが実行されている場所を把握する必要があります。

Wrapperバージョン3.5.6から、 「WRAPPER_INIT_DIR」 環境変数で、この初期ディレクトリーの場所を把握します。

ほとんどの場合、単純にこの値をアプリケーションへ引き渡したいと思うことでしょうが、 アプリケーションやそのログファイルの全てが、把握している場所で、書き込み可能であることを確認してください。 これで、システムプロパティ内でJVMへ配置場所を引き渡すことで可能になります。

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");

しかしながら、もし、本当にWrapperやアプリケーションディレクトリーに現在の配置場所を設定したい場合、 作業ディレクトリーに初期ディレクトリーの場所を設定することで実現することができます。 次の点にご留意ください、ログファイルやPIDファイルなどの配置場所を 常に確実に見つけられる固定の絶対パスで、たぶん設定したいと思っていることでしょうが、 Wrapperのコンフィギュレーションファイルは、なおも常にWrapperバイナリの場所から相対参照で、 ロード（読み込み）されます。

wrapper.working.dir=%WRAPPER_INIT_DIR%

環境変数は、「環境変数について」ページで詳しく説明されています。 ここでは、もう少し作業ディレクトリーに関わる２、３点の問題を取り上げます。

Wrapperでは２つの環境変数を設定し、直接的に作業ディレクトリーへ関連づけます。

• ［WRAPPER_BIN_DIR］変数 (ver. 3.3.0から) は、スタートアップ時に、常にWrapperバイナリの配置場所へ設定されます。 これは、作業ディレクトリーが変更されたとしても、 コンフィギュレーションファイル内で、後から参照ポイントとして利用されます。

• ［WRAPPER_WORKING_DIR］変数 (ver. 3.3.0から) は、少し複雑で、Wrapperコンフィギュレーションファイル内部から参照されるとき、実際には役に立ちません。 これには常にカレント作業ディレクトリーが設定され、 ［wrapper.working.dir］プロパティで指定された値へ再設定されます。 しかし、コンフィギュレーションファイル内の変数参照は、 コンフィギュレーションファイルがロード（読み込み）されて、置き換えられます。 その時点で一つ覚えておいてください、 それでもなお作業ディレクトリーにはWrapperバイナリの配置場所が設定されます。 この環境変数は、システムレベルで環境変数が求められたとき、 唯一、JVM内部やそのチャイルド（子）プロセスだけで便利です。

また、Wrapperコンフィギュレーションファイル内で、 ユーザーが自分の環境変数を定義することも可能です。 それらは解釈されると環境の中に設定されます。このため、ちょっとした嬉しいことができます。 次の例のとおり、「MYAPP_HOME」変数を作成して、 作業ディレクトリーを設定するだけでなく、他のプロパティ内でもそれを活用することもできます。 インクルードファイル（カスケード形式）でロード（読み込み）されると、 その環境変数もまた利用できるようになりますので、どうぞ念頭に置いておいてください。

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

この方法は、もし「wrapper.exe」が アプリケーションディレクトリー構造の外部範囲に置くことが必要とされる場合でも、利用することができます。 例えば、システム全体にわたるコマンドのような場合です。