または
Try NowBuy Now
Google

Locations of visitors to this page

WrapperStartStopApp インテグレーション (Windows)
WrapperStartStopApp インテグレーション (Windows)

インテグレーション方法の全般

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

概要

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

通例、この種のアプリケーションは、スタートアップ時にサーバー ソケットを開け、 シャットダウンのキッカケになる接続待ち状態になります。 [シャットダウン]あるいは[ストップ]クラスが起動し、アプリケーションに接続することによって、 シャットダウンのキッカケを引き起こします。

この種のアプリケーションを持つ環境下では、 アプリケーションを起動させる時には、最初のメソッド[スタート]クラスを呼び出したり、 アプリケーションのシャットダウン時には、[ストップ]クラスのメイン・メソッドを呼び出したり、 Wrapperは「クラスの呼び出し」で動作します。

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

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

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

操作方法の詳細

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

Tomcatをインストールする

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

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

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

「bin」ディレクトリー

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

{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サービスの1つとしてインストールやアンインストールしたりすることができます。

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

「lib」ディレクトリー

Wrapperのライブラリー・ファイルを格納する標準場所「lib」ディレクトリーが必要ですが、 Tomcatには、「lib」ディレクトリーは存在しませんので、 ここでは、Tomcatのホーム・ディレクトリー下に「common/lib」ディレクトリーを作成します。 以下の2つのファイルをTomcatの「lib」ディレクトリーにコピーしてください:

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

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_HOME}/logs

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

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

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

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

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

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

%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" ...

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

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

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

ECHO %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" ...

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

start "Tomcat" "D:\Sun\j2sdk1.4.0_03\bin\java"    -Djava.endorsed.dirs="..\bin;..\common\endorsed"
  -classpath "D:\Sun\j2sdk1.4.0_03\lib\tools.jar;..\bin\bootstrap.jar" -Dcatalina.base=".."
  -Dcatalina.home=".." -Djava.io.tmpdir="..\temp" org.apache.catalina.startup.Bootstrap  start

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

"D:\Sun\j2sdk1.4.0_03\bin\java"    -Djava.endorsed.dirs="..\bin;..\common\endorsed"
  -classpath "D:\Sun\j2sdk1.4.0_03\lib\tools.jar;..\bin\bootstrap.jar" -Dcatalina.base=".."
  -Dcatalina.home=".." -Djava.io.tmpdir="..\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:\Sun\j2sdk1.4.0_03\bin\java

Java引数

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

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

wrapper.java.additional.1=-Djava.endorsed.dirs=..\bin;..\common\endorsed
wrapper.java.additional.2=-Dcatalina.base=..
wrapper.java.additional.3=-Dcatalina.home=..
wrapper.java.additional.4=-Djava.io.tmpdir=..\temp

Note that all quotes have been removed as none of these paths will ever contain quotes. (プロパティがスペースを含む場合のケースについて取り扱い方の詳しくは、 プロパティの説明を読んでください)

クラスパス

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

wrapper.java.classpath.1=..\common\lib\wrapper.jar
wrapper.java.classpath.2=D:\Sun\j2sdk1.4.0_03\lib\tools.jar
wrapper.java.classpath.3=..\bin\bootstrap.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]ヘルパークラスを使っているときには、 [スタート]や[ストップ]の両クラスについて多くの情報が提供される必要があります。 その情報とは、各クラスの完全なクラス名や、 メイン・メソッドへ引き渡されるパラメーター・リスト、 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 which 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

[スタート]と[ストップ]クラス名は、明らかにクリアであるべきです。 1番目のパラメーター・カウントは、パラメーター・リストの[ストップ]クラスの配置に必要です。 2番目のカウントは、一貫性を保ち、続けてあります。

パラメーター5番のフラグは、JVMをシャットダウンしている時、 [WrapperStartStopApp]ヘルパークラスの動作をコントロールするために使われます。 WrapperがJVMシャットダウン・リクエストを送ると、 [WrapperStartStopApp]がその設定されたパラメーター値に従い、 [ストップ]クラスメイン・メソッドを呼び出して応答します。 上記のフラグは、メイン・メソッドが応答を返すと、何が起きるかをコントロールします。 もしフラグが「FALSE」なら、即座に[System.exit(0)]が呼び出されるでしょう。 フラグが「TRUE」なら、[WrapperStartStopApp]は、 [System.exit(0)]を呼び出す前に、全ての非デーモン・スレッドが完了するまで待機します。 後者の方が、Tomcatにとって、一番キレイなシャットダウンを起こす動作です。 「TRUE」が指定されていた場合でも、いくつか完了しないデーモン・スレッドもあり、 Wrapperは、[shutdown.timeout] のタイムアウト(時間切れ)の後、強制的にJVMを落とします。 このデフォルト値は「30秒」です。

システムにある全てのスレッドを繰り返したり、 [isDaemon]メソッドが「FALSE」を返してくるのをカウントしたりすることで、 非デーモン・スレッドがカウントされます。 不運にも、このカウントは、既存のシステム・スレッドのために、ほとんどのJVM上で実際のところゼロに達することはありません。 ほとんどのSun JVMに、1つは非デーモン・システム・スレッドがあるでしょう。 シャットダウン作業を正しく行うために、このシステム・スレッド・カウントが正しくある必要があり、[ org.tanukisoftware.wrapper.WrapperStartStopApp.systemThreadCount ]システム・プロパティで定義で設定することができます。このデフォルト値は「1スレッド」です。

注意

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

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

ライブラリーパス

Wrapperを使うために、設定しなければならないプロパティがもう一つあります。 システムとの対話をコントロールするため、Wrapperは、ネイティブ・ライブラリーを利用します。 このライブラリー・ファイル「wrapper.dll」は、 JVMへ供給されるライブラリーパスで指定しておく必要があります。 Tomcatでは、ネイティブ・ライブラリーを一切持ちません、 仮にあったとしても、 それがどこに位置するのか ライブラリーの配置場所(ディレクトリー)を指定しておく必要があるでしょう。 ライブラリーパスは、[ wrapper.java-library-path.<n> ]プロパティを使って設定します。

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

全部をまとめる

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

wrapper.java.command=D:\Sun\j2sdk1.4.0_03\bin\java

wrapper.java.additional.1=-Djava.endorsed.dirs=..\bin;..\common\endorsed
wrapper.java.additional.2=-Dcatalina.base=..
wrapper.java.additional.3=-Dcatalina.home=..
wrapper.java.additional.4=-Djava.io.tmpdir=..\temp
                        
wrapper.java.classpath.1=..\common\lib\wrapper.jar
wrapper.java.classpath.2=D:\Sun\j2sdk1.4.0_03\lib\tools.jar
wrapper.java.classpath.3=..\bin\bootstrap.jar

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

Tomcatのケースでは1つ例外があり、[ java.endorsed.dirs ]プロパティにUnixのパス・セパレーターを含んでいます。

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

wrapper.java.additional.1=-Djava.endorsed.dirs=../bin;../common/endorsed
wrapper.java.additional.2=-Dcatalina.base=..
wrapper.java.additional.3=-Dcatalina.home=..
wrapper.java.additional.4=-Djava.io.tmpdir=../temp

wrapper.java.classpath.1=../common/lib/wrapper.jar
wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.3=../bin/bootstrap.jar

wrapper.java.library.path.1=../common/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は継続せず、 アプリケーションの起動が確立するまで待機します。

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

wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.waitForStartMain=TRUE

タイムリーなマナーでメイン・メソッドが応答を返してくることが確実に分かっている場合には、 この『無期限の待機』のオプション設定は有意義な選択肢となるでしょう。 しかし、スタートアップ・プロセスでどんなに時間がかかろうが、 Wrapperは待機中に決してギブアップすることはなく、ひたすら待ち続けるでしょう。 もしスタートアップでハングアップする可能性を考えると、 その[org...WrapperStartStopApp.maxStartMainWait] システム・プロパティのオプション設定で「待機時間のタイムアップ最大時間」を設定しておくのが良いと思います。 スタートアップ・メイン・メソッドの起動確立に5分間まで待機させるには、 以下のようにプロパティに「300」(秒数)と設定してください (デフォルト値2秒):

wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.maxStartMainWait=300

注意

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

警告

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





User Comments

If you notice something that is incorrect, missing, or simply feel that some part of this page could be explained better, feel free to log in and add a comment. You will need to register before you can log on.

Email:
Password:
Java Service Wrapper Version: 3.4.0