World Map
Java Service Wrapperは、御社Javaアプリケーション製品の安定した信頼性を高める最短最善の方法です。
  • Free Trial
  • Buy Now
WrapperStartStopApp インテグレーション(Windows)

方法2 - WrapperStartStopApp インテグレーション(Windows)

概要

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

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

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

WrapperStartStopApp]ヘルパークラスが起動すると、 [start]クラスと[stop] クラスの両方のクラス名が言い渡されます。 同様に、各クラスのメインメソッドへ提供されるべき必要なパラメータも引き渡され、 これにより、結果として、アプリケーションパラメータでご覧のとおり、パラメータリストが仕上がり、 方法1(WrapperSimpleApp)ヘルパークラスのものより少し複雑になります。

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

操作方法の詳細

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

Tomcat をインストールする

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

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

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

「bin」ディレクトリー

まず始めに、以下のファイルを Tomcat の 「bin directory」ディレクトリーにコピーしてください。

{WRAPPER_HOME}\bin\wrapper.exe
{WRAPPER_HOME}\src\bin\App.bat.in
{WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in
{WRAPPER_HOME}\src\bin\UninstallApp-NT.bat.in

以下のように、アプリケーション名を反映して、3つのバッチファイル名を変更します。 拡張子「.in」を外して、 ファイルの拡張子が「.bat」で終わるように変更してください。

なお、ご利用のコンピューターの設定状況によっては、拡張子が見えない場合がありますので、 拡張子が表示されるよう事前に設定を変更する必要があるかもしれません。

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

{TOMCAT_HOME}\bin\Tomcat.bat
{TOMCAT_HOME}\bin\InstallTomcat-NT.bat
{TOMCAT_HOME}\bin\UninstallTomcat-NT.bat

wrapper.exe」ファイルは、実際の Wrapper 実行ファイルです。 3つのバッチファイルは、コンソールで Tomcat を動かすために使われ、 Tomcat を Windows サービスとしてインストールやアンインストールしたりすることができます。

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

「lib」ディレクトリー

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

{WRAPPER_HOME}\lib\wrapper.dll
{WRAPPER_HOME}\lib\wrapper.jar

Wrapper のライブラリーファイルを格納する標準場所 「lib」ディレクトリーが必要ですが、 Tomcat には、「lib」ディレクトリーは存在しませんので、 ここでは、Tomcat のホームディレクトリー下に「common/lib」ディレクトリーを作成します。 以下の2つのファイルをTomcatの「lib」ディレクトリーにコピーしてください: 「wrapper.dll」ファイルは、ネイティブライブラリー ファイルであり、 JVM 内で動作する Wrapper の部分に必要なものです。 「wrapper.jar」ファイルには、全ての Wrapper クラスが含まれています。

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

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

%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -classpath "%CLASSPATH%" ...

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

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

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

echo %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -classpath "%CLASSPATH%" ...

今、そのバッチファイルを再始動すると、コンソールに下記のようなものが表示されるでしょう(出力結果は全て一行で表示):

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

上記の「startup.bat」同様に、 「shutdown.bat」バッチファイルにも同じ手順を繰り返してください。 今、単純にバッチファイルを始動してみると、下記の出力が得られ、驚くかもしれませんが、 これは、パラメータを変更するだけで、「startup.bat」と「shutdown.bat」の 両者とも「catalina.bat」バッチファイルを呼び出しているためです。

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

スタートアップ行の初めにある「start Tomcat」以外では、 2つのコマンドはほとんど同等のものです。 唯一の違いは、最後にメインクラスへ渡されたパラメータです。 コマンドの「start Tomcat」部分は、コンソールに Tomcat を埋め込むだけに利用されています。 これは Wrapper の利用に影響がないため、ここでの以降の事例説明では、コマンド部を無視することにします。

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

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

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

注意

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

Java 実行ファイル

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

wrapper.java.command=D:\jdk1.8.0_45\bin\java

Java 引数

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

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

wrapper.java.additional.1=-Dcatalina.base=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=D:\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=D:\apache-tomcat-9.0.0.M13\conf\logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

これらのパスのどれも引用を含んでいないため、 全ての引用符が取り除かれていることに注意してください。 スペース(空白)を含むプロパティの扱い方については、プロパティの説明を参照してください。

クラスパス

次にクラスパスです。 [wrapper.java.classpath.<n>] プロパティを使って設定を変更します。 Wrapper では、クラスパスを個別のエレメントへ細分化する必要があります。 さらに、Wrapper も使っているので、 「wrapper.jar」ファイルも同様に含める必要があります。

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar
wrapper.java.classpath.2=D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar
wrapper.java.classpath.3=D:\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]クラス名は、明らかにクリアであるべきです。 1番目のパラメータカウントは、パラメータリストの[stop]クラスの配置に必要です。 2番目のカウントは、一貫性を保ち、続けてあります。

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

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

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

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

注意

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

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

ライブラリーパス

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

Tomcat では、ネイティブライブラリーを一切持ちませんが、仮にあったとしても、それがどこに位置するのか ライブラリーの配置場所(ディレクトリー)を指定しておく必要があるでしょう。

ライブラリーパスは、 [wrapper.java.library.path.<n>] プロパティを使って設定します。

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

全部をまとめる

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

wrapper.java.command=D:\jdk1.8.0_45\bin\java

wrapper.java.additional.1=-Dcatalina.base=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.2=-Dcatalina.home=D:\apache-tomcat-9.0.0.M13
wrapper.java.additional.3=-Djava.io.tmpdir=D:\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=D:\apache-tomcat-9.0.0.M13\conf\logging.properties
wrapper.java.additional.7=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

wrapper.java.classpath.1=D:\apache-tomcat-9.0.0.M13\lib\wrapper.jar
wrapper.java.classpath.2=D:\apache-tomcat-9.0.0.M13\bin\bootstrap.jar
wrapper.java.classpath.3=D:\apache-tomcat-9.0.0.M13\bin\tomcat-juli.jar

wrapper.java.library.path.1=D:\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.exe」ファイルが 存在する場所に設定するという仕組みの利点を生かし、 また、一つの環境変数を利用することで、上記のプロパティを変更することができるので、 完全にプラットフォームやマシンが依存しない独立型の状態となりえるのです。

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.java.classpath.1=..\lib\wrapper.jar
wrapper.java.classpath.2=..\bin\bootstrap.jar
wrapper.java.classpath.3=..\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

Windows サービスプロパティ

(参照:サポートされている Windows バージョン

最後のステップでは、 [Windows サービスプロパティ] の設定です。 ここでは変更すべきプロパティだけを取り上げます。 他にもいくつか有効なことはありますので、詳しくはそれぞれの使い方の説明を参照してください。 この変数の推奨された値は次のとおりです。

wrapper.ntservice.name=Tomcat
wrapper.ntservice.displayname=Tomcat Application Server
wrapper.ntservice.description=Tomcat Application Server

試しに動かしてみる

ここまで来れば、単純に「bin\Tomcat.bat」バッチファイルを実行することで Tomcat を動かすことができます。 Wrapper がカレントディレクトリーを設定してくれるお陰で、 「bin」ディレクトリー内部から、このバッチファイルを実行する必要はありません。 アプリケーションをサービスとして動かしてみる前に、コンソールアプリケーションとして動かしてみて、設定が有効になっているか確認してください。

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

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

上級者向け

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

デフォルトでは、[WrapperStartStopApp] クラスが2秒間待機して、ユーザーアプリケーションのメインメソッドの確立を待ちます。 その後、アプリケーションがスタートしたものとして解釈して、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] システムプロパティのオプション設定で「待機時間のタイムアウト(時間切れ)」を設定しておくのが良いと思います。 スタートアップメインメソッドの起動確立に5分間(300 秒間)まで待機させるには、以下のようにプロパティを「300」に設定してください。

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

設定例:(300 秒)
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait=300

注意

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

警告

スタートメソッドが応答を返してこないアプリケーション用に、 [waitForStartMain]を「TRUE」に設定した場合、 Wrapper は一見、正しく動作しているように見えるかもしれませんが、実は Wrapper はエンドレスで永久に待機状態であり、 決して稼働状態に入ることはないでしょう。 つまり、これは、Windows サービスマネージャーや、いくつかの Wrapper のエラーリカバリー(回復)の仕組みが正しく動作していない、ということです。