方法２ - WrapperStartStopApp インテグレーション（Linux / UNIX）

概要

方法２は、［WrapperStartStopApp］ヘルパークラスを使う手法です。 この手法は、「１つのクラス（例えば［start］クラス）を使用して開始し、 別のクラス（例えば［stop］クラス）で停止する」 という Tomcat のようなアプリケーションを利用している環境下でのインテグレーションに適している手法です。

通例、この種のアプリケーションは、スタートアップ時にサーバー ソケットを開け、シャットダウンのキッカケになる接続待ち状態になります。 ［シャットダウン］あるいは［stop］クラスが起動し、アプリケーションに接続することによって、 シャットダウンのキッカケを引き起こします。 この種のアプリケーションを持つ環境下では、 アプリケーションを起動させる時には、方法１と同様、［start］クラスを呼び出したり、 アプリケーションのシャットダウン時には、［stop］クラスのメインメソッドを呼び出したり、 Wrapper は「クラスの呼び出し」で動作します。

この方法２でインテグレーションすると、［WrapperStartStopApp］ヘルパークラスが アプリケーションのメインクラスを置き換えます。 これにより、［WrapperStartStopApp］クラスが、 即時に WrapperManager を初期化する機会を持つことができ、 JVM を Wrapper に登録します。 ［WrapperStartStopApp］クラスは、 アプリケーションのライフサイクル（稼働状況）はもちろんのこと、Wrapper との全ての対話を管理します。 WrapperManager 経由で Wrapper がスタートメッセージを JVM に送ると、 アプリケーションの［start］クラスのメインメソッドが呼び出されます。 同様に、Wrapper がストップメッセージを JVM に送ると、 アプリケーションの［stop］クラスのメインメソッドが呼び出されます。

［WrapperStartStopApp］ヘルパークラスが起動すると、 ［start］クラスと［stop］ クラスの両方のクラス名が言い渡され、 同様に、各クラスのメインメソッドへ提供されるべき必要なパラメータも引き渡されます。 これにより、結果として、パラメータリストが仕上がり、 方法１（WrapperSimpleApp）ヘルパークラスのものより少し複雑になります。

［WrapperStartStopApp］クラスへ引き渡される最初のパラメータは、 ［start］クラスの完全なフルクラス名となります。 次にくる［start］クラスのメインメソッドへパラメータカウントが、続きます。 その［start］クラスのパラメータの後に続き、 その［stop］クラスの完全なフルクラス名がきます。 これは［TRUE/FALSE］フラグに応対して動き、そのフラグにより、実際の終了前に、 全ての非デーモンスレッドが完了するまで待つべきかどうかの指示が、 ［WrapperStartStopApp］クラスに伝えられます。このフラグの後に、 ［stop］クラスのパラメータやパラメータカウントが続きます。 これらの説明が複雑で理解できなくても心配する必要はありません。下記に詳細の例をご紹介しています。

操作方法の詳細

このセクションでは、さらに詳細に踏み込み、Wrapper 内でアプリケーションを動かすためにはどうするのか、 Tomcat 設定方法を例にあげて説明します。 その他のほとんどのアプリケーションは、同様の手順でインテグレーションすることができます。

Tomcat をインストールする

ここでの解説は、Tomcat のクリーンインストールから進める手順で説明します。 ここでは「Tomcat バージョン 9.0.0.M13」を利用していますが、 バージョンの違いなどにより手順が部分的に異なる場合があります。 Tomcat はディレクトリー（/usr/lib）にインストールされています。 従って Tomcat のホームディレクトリーは「/usr/lib/apache-tomcat-9.0.0.M13」となります。

Wrapper ファイルをインストールする

Wrapper を使えるようにするために４つのディレクトリーを操作する必要があります。

注意

動作しているプラットフォーム用にビルドされた適切なバージョンの Wrapper と 「libwrapper.so」ファイルであることを確認してください。 例えば、Wrapper Linux 版は、Solaris 上では動作しません。

bin directory

Wrapper にシェルスクリプト（sh）を同梱して提供しており、 それを使うことで、Java アプリケーションを Java Service Wrapper でコントロールし、 確実に開始したり停止したりすることができます。

まず始めに、以下のファイルを Tomcat の「bin」ディレクトリーにコピーしてください。（Wrapper の旧バージョンのファイル名：「sh.script.in」） 

{WRAPPER_HOME}/bin/wrapper
{WRAPPER_HOME}/src/bin/App.sh.in

アプリケーション名を反映してスクリプトファイル名を変更します。 

{TOMCAT_HOME}/bin/tomcat

次に、エディターで、そのスクリプトを開きます。 Tomcat を起動する際のスクリプトで表示が反映されるように、 ロング名やショート名を設定が必要です。スクリプトのヘッダーの直後に、 ２つの変数［APP_NAME］と［APP_LONG_NAME］が見えるでしょう。 この変数の推奨された値は次のとおりです。 

APP_NAME="tomcat"
APP_LONG_NAME="Tomcat Application Server"

これらのバッチファイルは、何も設定変更を必要としませんが、コンフィギュレーションファイル 「wrapper.conf」が 一つ上の階層（../conf/wrapper.conf）の 「conf」ディレクトリーにあるという前提で進めていきます。 もし、その「../conf/wrapper.conf」ファイルを他の場所に設置したい場合には、 そのスクリプト内の［WRAPPER_CONF］変数を変更する必要があります。

注意

重要！ 処理を進める前に、処理を進める前に、 「bin」ディレクトリー内へコピーされたすべてのファイルに、 実行可能フラグが付いていることを確認してください。

「lib」ディレクトリー

以下の２つのファイルを Tomcat の「lib」ディレクトリーにコピーしてください： 

{WRAPPER_HOME}/lib/libwrapper.so
{WRAPPER_HOME}/lib/wrapper.jar

「libwrapper.so」ファイルは、 ネイティブライブラリーファイルであり、 JVM 内で動作する Wrapper の部分に必要なものです。 「wrapper.jar」ファイルには、全ての Wrapper クラスが含まれています。

注意

プラットフォームによっては、ネイティブライブラリの命名規則が若干異なることに注意してください。 可能な名前は、 「libwrapper.a」、 「libwrapper.sl」、 「libwrapper.so」、 と「libwrapper.jnilib」を含みます。 いずれにせよ、拡張子を変更せずにファイルをコピーする必要があります。

「conf」ディレクトリー

Wrapper では各アプリケーション用の設定ファイル（コンフィギュレーションファイル 「wrapper.conf」）が必要です。 その設定ファイルの標準配置ディレクトリーは、 アプリケーションホームディレクトリー下の「conf」ディレクトリーです。 以下の設定ファイルテンプレート「wrapper.conf.in」を Tomcat の「conf」ディレクトリーにコピーしてください。 

{WRAPPER_HOME}/src/conf/wrapper.conf.in

ファイル名の「.in」拡張子を外して、 ファイル名を「wrapper.conf」へ変更します。

以下のようになるはずです： 

{TOMCAT_HOME}/conf/wrapper.conf

もしコンフィギュレーションファイル「wrapper.conf」 の配置場所を変更したい場合には、自由に変更して構いませんが、 新しい場所が反映されるように、 上記の「bin」ディレクトリーの中に コピーしたスクリプトを変更する必要があります。

「logs」ディレクトリー

コンフィギュレーションファイル 「wrapper.conf」 のデフォルトでは、アプリケーションホームディレクトリー下にある 「logs」ディレクトリーの中に 「wrapper.log」ファイルを配置します。 Tomcat には、既にそのディレクトリを持っているので、こでれ準備が整いました。 

{TOMCAT_HOME}/logs

もし「wrapper.log」ファイルを他の場所に配置したい場合には、 「wrapper.conf」ファイルを編集して、新しい場所が反映されるように ［wrapper.logfile］ プロパティを変更する必要があります。

アプリケーションの Java コマンドラインの配置

Wrapper がアプリケーションを起動できるように Wrapper の設定を変更する前に、 通常使う完全な Java コマンドを知っておく必要があります。

ほとんどのアプリケーションでは、スクリプトを活用し、実際のコマンドラインを操作します。 一般的に、ほとんどのスクリプトは、扱いにくい傾向にありますが、 実際のところ、Wrapper の優れた機能により、 それらのスクリプトと無関係に動かすことができるのも、Wrapper メリットの一つなのです。

Tomcat は、「startup.sh」と呼ばれるバッチファイルを使って起動し、 「shutdown.sh」と呼ばれるスクリプトを使ってシャットダウンします。 まずカレントディレクトリーを「bin」ディレクトリーへ変更して、そこから起動します。 「startup.sh」をエディターで開いてみると、気づくと思いますが、 実は、Java はこのバッチファイルによって起動されているわけではないのです。 実際のところ、「catalina.sh」という名前のバッチファイルが呼び出されています。 Tomcat のスクリプトはとても高度にできていて、ユーザーがコマンドラインから多様な設定ができるようになっています。 Wrapper で利用したりキャプチャしたりするコマンドラインは、実際にはそういったコンフィギュレーションの １つのスナップショットなのです。 具体例をあげてみると、稼働時には、スタートアップスクリプトにもシャットダウンスクリプトにも、 パラメータが渡されていません。

「catalina.sh」をエディターで開いて、一番下までスクロールしてみると、 Java を起動する４行のラインが見えます。 デフォルトのまま利用しており、最初のラインが使われます。注目するラインは、次のとおりです： （実際のコマンドはとても長いので抜粋しています。） 

eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  -classpath "\"$CLASSPATH\"" \
  -Dcatalina.base="\"$CATALINA_BASE\"" \
  -Dcatalina.home="\"$CATALINA_HOME\"" \
  -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  org.apache.catalina.startup.Bootstrap "$@" start \
  >> "$CATALINA_OUT" 2>&1 "&"

スクリプトの大部分には、システム固有の情報を収集して、 その情報を環境変数の中に格納するタスク機能を備えています。 上記の行を明記することにより、収集した全ての情報を最終の Java コマンドへと拡張させ、それでアプリケーションを起動させることになります。

そのスクリプトのソースを見れば分かるとおり、 複雑なスクリプトで高機能を備えたものだと評価したり、 複雑なスクリプトを書く面倒から完全に免れられる喜びなど、 皆様の様々な希望を叶えているものだろうと、私達は願っています。

Wrapper の設定で、本当に必要な個所は、 その最後の拡張コマンドラインなのです。 スクリプト全体を読みこなしたり、理解しようと試みるよりは、 むしろ、ちょっとした簡単な小細工をしかけることで、 コンソールで最終コマンドラインを表示させることができます。 以下のように「catalina.sh」スクリプトを編集してください。 

#eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  #-classpath "\"$CLASSPATH\"" \
  #-Dcatalina.base="\"$CATALINA_BASE\"" \
  #-Dcatalina.home="\"$CATALINA_HOME\"" \
  #-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  #org.apache.catalina.startup.Bootstrap "$@" start \
  #>> "$CATALINA_OUT" 2>&1 "&"
echo "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
  -classpath "\"$CLASSPATH\"" \
  -Dcatalina.base="\"$CATALINA_BASE\"" \
  -Dcatalina.home="\"$CATALINA_HOME\"" \
  -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  org.apache.catalina.startup.Bootstrap "$@" start"

今、そのスクリプトを再始動すると、コンソールに下記のようなものが表示される でしょう（出力結果は全て一行で表示）： 

/opt/jdk1.8.0_45/bin/java
  "-Djava.util.logging.config.file=/usr/lib/apache-tomcat-9.0.0.M13/conf/logging.properties" 
  -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
  -Djdk.tls.ephemeralDHKeySize=2048 
  -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
  -classpath "/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar:/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar" 
  -Dcatalina.base="/usr/lib/apache-tomcat-9.0.0.M13" 
  -Dcatalina.home="/usr/lib/apache-tomcat-9.0.0.M13" 
  -Djava.io.tmpdir="/usr/lib/apache-tomcat-9.0.0.M13/temp" 
  org.apache.catalina.startup.Bootstrap start

［stop］コマンドには、上記と同様に同じ手順を繰り返してください。 今、単純にバッチファイルを始動してみると、下記の出力が得られ、驚くかもしれませんが、 エディターを下へスクロールし［stop］コマンドを探してください。 

exec "$_RUNJAVA" $JAVA_OPTS \
  -classpath "$CLASSPATH" \
  -Dcatalina.base="$CATALINA_BASE" \
  -Dcatalina.home="$CATALINA_HOME" \
  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
  org.apache.catalina.startup.Bootstrap "$@" stop

もう一度、このセクションを下記のように変更してください。 

#exec "$_RUNJAVA" $JAVA_OPTS \
  #  -classpath "$CLASSPATH" \
  #  -Dcatalina.base="$CATALINA_BASE" \
  #  -Dcatalina.home="$CATALINA_HOME" \
  #  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
  #  org.apache.catalina.startup.Bootstrap "$@" stop
echo "exec $_RUNJAVA $JAVA_OPTS" \
    "-classpath $CLASSPATH" \
    "-Dcatalina.base=$CATALINA_BASE" \
    "-Dcatalina.home=$CATALINA_HOME" \
    "-Djava.io.tmpdir=$CATALINA_TMPDIR" \
    "org.apache.catalina.startup.Bootstrap $@ stop"

［catalina.sh stop］スクリプトを再始動すると、コンソールに下記のようなものが表示される でしょう（出力結果は全て一行で表示）： 

exec /opt/jdk1.8.0_45/bin/java
  -Djdk.tls.ephemeralDHKeySize=2048 
  -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
  -classpath "/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar:/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar" 
  -Dcatalina.base="/usr/lib/apache-tomcat-9.0.0.M13" 
  -Dcatalina.home="/usr/lib/apache-tomcat-9.0.0.M13"
  -Djava.io.tmpdir="/usr/lib/apache-tomcat-9.0.0.M13/temp" 
  org.apache.catalina.startup.Bootstrap stop

シャットダウン行の初めにある「exec」以外に、 リダイレクトされたスタートアップ行の出力はほとんど同等のものです。 唯一の違いは、最後にメインクラスへ渡されたパラメータです。 シャットダウンコマンドの「exec」部分とコンソール出力をキャプチャするための リダイレクト分は Wrapper 利用時に必要がないため、ここでの以降の事例説明では、 コマンド部を無視することにします。

また、Wrapper は、ビルドする Java コマンドラインのエレメントの引用も扱いますので、 下記のコンフィギュレーションファイル「wrapper.conf」へ引き継ぐ必要はありません。

コンフィギュレーションファイル「wrapper.conf」の変更

もし、上記のコマンドラインを Wrapper で使うためには、そのコマンドラインのコンポーネントを細分化して、 コンフィギュレーションファイルへ落とし込んでいく必要があります。 「wrapper.conf ファイルをエディターで開き、下記のようにプロパティに変更を加えてください。

注意

下記の文中で説明しているプロパティについて、 そのリンク先では、それぞれ詳しい説明を提供しています。 じっくり時間をかけて、 変更するプロパティの説明を全部、熟読してください。 多くのケースでは、ここでは触れていない事項についても、さらに詳しい使い方の説明があります。

Java 実行ファイル

まず、Java 実行ファイルを解凍して、その配置場所のパスを ［wrapper.java.command］ プロパティにへ割り当てます。 

wrapper.java.command=/opt/jdk1.8.0_45/bin/java

Java 引数

ほとんどのアプリケーションは、起動時に、Java 実行ファイルへ、数多くのパラメータを提供します。 Wrapper では、クラスやライブラリーパス同様にメモリのような物事を設定するのために 特別なプロパティを提供しています。 これについては後で述べますが、その他の設定は、 ［wrapper.java.additional.<n>］ シリーズのプロパティを使って設定変更します。

Tomcat コマンドラインは、そのようなプロパティがいくつかあります： 

wrapper.java.additional.1=-Dcatalina.base=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=/usr/lib/apache-tomcat-9.0.0.M13/temp
wrapper.java.additional.4=-Djdk.tls.ephemeralDHKeySize=2048
wrapper.java.additional.5=-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
# Following properties are optional:
wrapper.java.additional.6=-Djava.util.logging.config.file=/usr/lib/apache-tomcat-9.0.0.M13/conf/logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Wrapper Jar

「wrapper.jar」ファイルを指定する必要があります。 

wrapper.jarfile=/usr/lib/apache-tomcat-9.0.0.M13/lib/wrapper.jar

警告

［wrapper.jarfile］プロパティは、Wrapper ver. 3.5.55 で導入されました。 それより前の Wrapper バージョンを利用する場合、クラスパスに「wrapper.jar」を追加する必要があります。 

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar

そして、［wrapper.java.classpath.1］プロパティが重複しないように、次のクラスパス要素のインデックスを調整する必要があります。

クラスパス

次にクラスパスです。 ［wrapper.java.classpath.<n>］ プロパティを使って設定を変更します。 Wrapper では、クラスパスを個別のエレメントへ細分化する必要があります。 

wrapper.java.classpath.1=/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar
wrapper.java.classpath.2=/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar

メインクラス

Tomcat を起動するのに使われるコマンドの次のコンポーネントは、 メインクラス［org.apache.catalina.startup.Bootstrap］です。 起動時に Java によって実行されるこのメインクラスは、 ［wrapper.java.mainclass］ プロパティを使って指定します。 しかしながら上記で述べたように、［WrapperStartStopApp］ ヘルパークラスを使って Tomcat を開始したり停止したりしているので、 メインクラスとして、完全なフルクラス名を指定します。 Tomcat メインクラスは、アプリケーションパラメータとして以下のように指定されています。 

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

アプリケーションパラメータ

アプリケーションパラメータの設定方法について、 ［wrapper.app.parameter.<n>］プロパティページをご覧ください。 アプリケーションパラメータは、メインクラスの後、Java コマンドラインに直接表示されます。

［WrapperStartStopApp］ヘルパークラスを使っているときには、 ［start］や［stop］の 両クラスについて多くの情報が提供される必要があります。 その情報とは、各クラスの完全なクラス名や、メインメソッドへ引き渡されるパラメータリスト、 JVM 終了前に全ての非デーモンスレッドの終了を待つべきかどうかの判断をヘルパークラスへ 指示するフラグなどが含まれています。

この全ての情報がどのようにエンコードされるのか明確にするために、 Tomcat アプリケーション用にプロパティ値を提供するところから始めており、プロパティが意味することを明確にするために、 「wrapper.conf」ファイルに通常含まれるべきものは何か、 いくつかのコメントを付加してあります。 ご自分のコンフィギュレーションファイル「wrapper.conf」 にも同様にコメントを付加することをお勧めします。 

# The first application parameter is the name of the class whose main
# method is to be called when the application is launched.  The class
# name is followed by the number of parameters to be passed to its main
# method.  Then comes the actual parameters.
wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start

# The start parameters are followed by the name of the class whose main
# method is to be called to stop the application.  The stop class name
# is followed by a flag that controls whether or not the Wrapper should
# wait for all non daemon threads to complete before exiting the JVM.
# The flag is followed by the number of parameters to be passed to the
# stop class's main method.  Finally comes the actual parameters.
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

［start］と［stop］クラス名は、明らかにクリアであるべきです。 １番目のパラメータカウントは、パラメータリストの［stop］クラスの配置に必要です。 ２番目のカウントは、一貫性を保ち、続けてあります。

上記パラメータ #5 のフラグは、JVM をシャットダウンしている時、 ［WrapperStartStopApp］ヘルパークラスの動作をコントロールするために使われます。 Wrapper が JVM シャットダウンリクエストを送ると、 ［WrapperStartStopApp］がその設定されたパラメータ値に従い、 ［stop］クラスメインメソッドを呼び出して応答します。 上記のフラグは、メインメソッドが応答を返すと、何が起きるかをコントロールします。

もしフラグが「FALSE」なら、即座に［System.exit(0)］が呼び出されるでしょう。 フラグが「TRUE」なら、［WrapperStartStopApp］は、 ［System.exit(0)］を呼び出す前に、 全ての非デーモンスレッドが完了するまで待機します。 後者の方が、Tomcat にとって、一番キレイなシャットダウンを起こす動作です。 「TRUE」が指定されていた場合でも、いくつか完了しないデーモンスレッドもあり、 Wrapper は、［Shutdown Timeout］ のタイムアウト（時間切れ）の後、強制的に JVM を落とします。 デフォルト値は「３０秒」です。

システムにある全てのスレッドを繰り返したり、 ［isDaemon］メソッドが「FALSE」を返してくるのを カウントしたりすることで、非デーモンスレッドがカウントされます。 不運にも、このカウントは、既存のシステムスレッドのために、ほとんどの JVM 上で実際のところ「0」（ゼロ）に達することはありません。

ほとんどの Oracle Hotspot JVM に、１つは非デーモンシステムスレッドがあるでしょう。 シャットダウン作業を正しく行うために、このシステムスレッドカウントが正しくある必要があり、 ［org.tanukisoftware.wrapper.WrapperStartStopApp.systemThreadCount］ システムプロパティで定義することができます。 デフォルト値は「１スレッド」です。

注意

もし、［stop］クラスのメインメソッドがそのメインスレッドから ［System.exit］を呼び出すと、そのスレッドは、この呼び出しコールにより、 実質的にデッドロック（致命的な事態）になってしまうでしょう。 Wrapper では、これを検知することや、５秒後にシャットダウンの処理を進めることで、デッドロックを避けることができます。 しかしながら、これは、アプリケーションが落ちてキレイにシャットダウンし損ねる結果に なるかもしれませんので、可能ならば利用を避けるべきです。

このケースは、［wrapper.debug=TRUE］プロパティを有効にすることでテストすることができます。 その後、シャットダウンプロセスのログファイルを確認します。

ライブラリーパス

Wrapper を使うために、設定しなければならないプロパティがもう一つあります。 システムとの対話をコントロールするため、Wrapper は、 ネイティブライブラリーを利用します。 このライブラリーファイル 「libwrapper.so」は、 JVM へ供給されるライブラリーパスで指定しておく必要があります。

Tomcat では、ネイティブライブラリーを一切持ちませんが、仮にあったとしても、 それがどこに位置するのかライブラリーの配置場所（ディレクトリー）を指定しておく必要があるでしょう。 ライブラリーパスは、 ［wrapper.java.library.path.<n>］ プロパティを使って設定します。 

wrapper.java.library.path.1=/usr/lib/apache-tomcat-9.0.0.M13/lib

全部をまとめる

全部をまとめると、下記のようになります： 

wrapper.java.command=/opt/jdk1.8.0_45/bin/java

wrapper.java.additional.1=-Dcatalina.base=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=/usr/lib/apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=/usr/lib/apache-tomcat-9.0.0.M13/temp
wrapper.java.additional.4=-Djdk.tls.ephemeralDHKeySize=2048
wrapper.java.additional.5=-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
#following properties are optional:
wrapper.java.additional.6=-Djava.util.logging.config.file=/usr/lib/apache-tomcat-9.0.0.M13/conf/logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

wrapper.jarfile=/usr/lib/apache-tomcat-9.0.0.M13/lib/wrapper.jar

wrapper.java.classpath.1=/usr/lib/apache-tomcat-9.0.0.M13/bin/bootstrap.jar
wrapper.java.classpath.2=/usr/lib/apache-tomcat-9.0.0.M13/bin/tomcat-juli.jar

wrapper.java.library.path.1=/usr/lib/apache-tomcat-9.0.0.M13/lib

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

これらの設定をしたマシンが正常に動作していることからも分かるように、 ディレクトリー構造やプラットフォームに非常に高く依存しています。 Wrapper のスクリプトは常に作業ディレクトリーをスクリプトが 存在する場所に設定するという仕組みの利点を生かし、 また、一つの環境変数を利用することで、上記のプロパティを変更することができるので、 完全にプラットフォームやマシンが依存しない独立型の状態となりえるのです。 

wrapper.java.command=%JAVA_HOME%/bin/java

wrapper.java.additional.1=-Dcatalina.base=..
wrapper.java.additional.2=-Dcatalina.home=..
wrapper.java.additional.3=-Djava.io.tmpdir=../temp
wrapper.java.additional.4=-Djdk.tls.ephemeralDHKeySize=2048
wrapper.java.additional.5=-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
#following properties are optional:
wrapper.java.additional.6=-Djava.util.logging.config.file=../conf/logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

wrapper.jarfile=../lib/wrapper.jar

wrapper.java.classpath.1=../bin/bootstrap.jar
wrapper.java.classpath.2=../bin/tomcat-juli.jar

wrapper.java.library.path.1=../lib

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp

wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=TRUE
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

注意

もし「bin」ディレクトリーが［java.endorsed.dirs］システムプロパティに含まれている場合、 「Tomcat 5.0.28」では、正しく動作しないという報告があがっています。 これは、Wrapper の問題ではなく、むしろ Tomcat 内部の変更の問題によって引き起こされているのが原因です。 上記の設定を下記のように変更してください。 

wrapper.java.additional.1=-Djava.endorsed.dirs=../common/endorsed

試しに動かしてみる

ここまで来れば、単純に「bin/tomcat console」スクリプトを実行することで Tomcat を動かすことができます。 Wrapper がカレントディレクトリーを設定してくれるお陰で、 「bin」ディレクトリー内部から、このバッチファイルを実行する必要はありません。

ご覧のとおり、コマンドを省略すると、Wrapper に同梱して提供しているスクリプトは、 極めて標準的なデーモンスクリプトです。 ［console］、 ［start］、 ［stop］、 ［restart］、 ［dump］ コマンドを受け付ます。 ［start］、 ［stop］、 ［restart］コマンドは、ほとんどのデーモンスクリプトでは 一般的なもので、Wrapper やデーモンプロセスとしてのアプリケーションをコントロールするために使われます。 ［status］コマンドは、Wrapper が現在稼働中かどうか検知するために使われます。 ［console］コマンドは、カレントシェル内で、Wrapper を起動し、［CTRL］＋［C］のキー操作でアプリケーションを任意停止することを可能にします。 ［dump］コマンドは、JVM にフルスレッドダンプをさせるように仕向けるために、Wrapper へ「kill -3」シグナルを送ります。

おめでとう！あなたのアプリケーションが起動して動き始めるはずです。

もし何か問題があった場合、トラブルシューティングをご覧いただき、 問題点を追究するのに役立つことでしょう。

上級者向け

スタートアップを調整する

デフォルトでは、［WrapperStartStopApp］ クラスが２秒間待機して、ユーザーアプリケーションのメインメソッドの確立を待ちます。 その後、アプリケーションがスタートしたものとして解釈して、Wrapper プロセスに報告します。 これは、多くのユーザーアプリケーションが応答を返してこないメインメソッドで書かれているため、 そのように処理を進めています。 そのようなケースでは、アプリケーションが無事にスタートアップしたのか、 スタートアップが完了したのか言及できず、 ［WrapperStartStopApp］クラスにとっては頼れる手段がありません。

しかしながら、もし、アプリケーションのメインメソッドが、アプリケーションの開始応答を 一旦戻してくる場合には、Wrapper にとっては理想的なことであり、Wrapper は継続せず、 アプリケーションの起動が確立するまで待機します。

waitForStartMain システムプロパティ：

このように応答を返してくるメインメソッドに対しては、［WrapperStartStopApp］が ［org.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain］ システムプロパティを探し、もし「TRUE」に設定されていた場合、 ［WrapperStartStopApp］は アプリケーションのメインメソッドが完了するまで無期限に待機します。

設定例：（待機あり） 
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain=TRUE

maxStartMainWait システムプロパティ：

タイミング良くメインメソッドが応答を返してくることが確実に分かっている場合には、 この『無期限の待機』のオプション設定は有意義な選択肢となるでしょう。 しかし、スタートアップ処理でどんなに時間がかかろうが、Wrapper は待機中に 決してギブアップすることはなく、ひたすら待ち続けるでしょう。

もしスタートアップでハングアップする可能性を考えると、 その［org.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait］ システムプロパティのオプション設定で「待機時間のタイムアウト（時間切れ）」を 設定しておくのが良いと思います。 スタートアップメインメソッドの起動確立に５分間（300 秒間）まで待機させるには、以下のようにプロパティを「300」に設定してください。

デフォルト値は「２秒」です。

設定例：（300 秒） 
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait=300

注意

多くのアプリケーションのメインメソッドでは応答を返してこない設計になっています。 その場合、デフォルト値２秒のスタートアップのタイムアウトをそのまま利用するか、あるいは、 アプリケーションのスタートアップに要する時間数を測定して、やや長めのタイムアウト時間を ［maxStartMainWait］プロパティを使って 指定するか、どちらかを必ず選ばなくてはなりません。

警告

スタートメソッドが応答を返してこないアプリケーション用に、 ［waitForStartMain］を「TRUE」に設定した場合、 Wrapper は一見、正しく動作しているように見えるかもしれませんが、実は Wrapper はエンドレスで永久に待機状態であり、 決して稼働状態に入ることはないでしょう。