または
Try NowBuy Now

Locations of visitors to this page

SourceForge.net

SourceForge.JP

WrapperStartStopApp インテグレーション (Linux / Unix)
WrapperStartStopApp インテグレーション (Linux / Unix)

インテグレーション方法

方法2 - WrapperStartStopApp インテグレーション (Linux / Unix)

概要

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

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

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

この方法2([WrapperStartStopApp]ヘルパークラス)でインテグレーションすると、 [WrapperStartStopApp]クラスがアプリケーションのメイン・クラスを置き換えます。 これにより、[WrapperStartStopApp]クラスが、 即時にWrapperManagerを初期化する機会を持つことができ、 JVM(Javaバーチャルマシン)を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バージョン4.1.18」を利用していますが、 バージョンの違いなどにより手順が部分的に異なる場合があります。 Tomcatは「/usr/lib」ディレクトリーにインストールされています、 従ってTomcatのホーム・ディレクトリーは「/usr/lib/jakarta-tomcat-4.1.18」となります。

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

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

注意

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

「bin」ディレクトリー

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

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

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

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

{TOMCAT_HOME}/bin/tomcat

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

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

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

注意

重要! 処理を進める前に、処理を進める前に、 「bin」ディレクトリーにコピーした全てのファイルが、 実行可能なビット・セットになっていることを確認してください。

「lib」ディレクトリー

Wrapperのライブラリー・ファイルを格納する標準場所 「lib」ディレクトリーが必要ですが、 Tomcatには、「lib」ディレクトリーは存在しませんので、 ここでは、Tomcatのホーム・ディレクトリー下に「common/lib」ディレクトリーを作成します。 以下の2つのファイルを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_HOME}/logs

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

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

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

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

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

catalina.sh」をエディターで開いて、 一番下までスクロールしてみると、[start]コマンドに応答するセクションが見えます。 JVMを起動する際に、セキュリティ・マネージャーを使う/使わない、 オプションが2つあります。事をシンプルにするために、 ここではセキュリティ・マネージャー使わない選択にします。 注目するラインは、以下のとおりです:

    "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
      -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
      -Dcatalina.base="$CATALINA_BASE" \
      -Dcatalina.home="$CATALINA_HOME" \
      -Djava.io.tmpdir="$CATALINA_TMPDIR" \
      org.apache.catalina.startup.Bootstrap "$@" start \
      >> "$CATALINA_BASE"/logs/catalina.out 2>&1 &

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

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

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

    #"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
    #  -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
    #  -Dcatalina.base="$CATALINA_BASE" \
    #  -Dcatalina.home="$CATALINA_HOME" \
    #  -Djava.io.tmpdir="$CATALINA_TMPDIR" \
    #  org.apache.catalina.startup.Bootstrap "$@" start \
    #  >> "$CATALINA_BASE"/logs/catalina.out 2>&1 &
    echo "$_RUNJAVA $JAVA_OPTS $CATALINA_OPTS " \
      "-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH" \
      "-Dcatalina.base=$CATALINA_BASE" \
      "-Dcatalina.home=$CATALINA_HOME" \
      "-Djava.io.tmpdir=$CATALINA_TMPDIR" \
      "org.apache.catalina.startup.Bootstrap $@ start" \
      ">> $CATALINA_BASE/logs/catalina.out 2>&1 &"

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

/opt/IBMJava2-131/bin/java
  -Djava.endorsed.dirs=/usr/lib/jakarta-tomcat-4.1.18/bin:/usr/lib/jakarta-tomcat-4.1.18/common/endorsed
  -classpath /opt/IBMJava2-131/lib/tools.jar:/usr/lib/jakarta-tomcat-4.1.18/bin/bootstrap.jar
  -Dcatalina.base=/usr/lib/jakarta-tomcat-4.1.18 -Dcatalina.home=/usr/lib/jakarta-tomcat-4.1.18
  -Djava.io.tmpdir=/usr/lib/jakarta-tomcat-4.1.18/temp org.apache.catalina.startup.Bootstrap start
  >> /usr/lib/jakarta-tomcat-4.1.18/logs/catalina.out 2>&1 &

上記の「startup.sh」スクリプト同様に、 「shutdown.sh」スクリプトにも同じ手順を繰り返してください。 「shutdown.sh」をエディターで開いてスクロールして、 上記で編集したセクションの直下に[stop]コマンドを設置してください:

  exec "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
    -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -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 $CATALINA_OPTS \
  #  -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -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 $CATALINA_OPTS" \
    "-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH" \
    "-Dcatalina.base=$CATALINA_BASE" \
    "-Dcatalina.home=$CATALINA_HOME" \
    "-Djava.io.tmpdir=$CATALINA_TMPDIR" \
    "org.apache.catalina.startup.Bootstrap $@ stop"

ここで、「shutdown.sh」スクリプトを始動すると、 コンソールに下記のようなものが表示されるでしょう (出力結果は全て一行で表示):

exec /opt/IBMJava2-131/bin/java
  -Djava.endorsed.dirs=/usr/lib/jakarta-tomcat-4.1.18/bin:/usr/lib/jakarta-tomcat-4.1.18/common/endorsed
  -classpath /opt/IBMJava2-131/lib/tools.jar:/usr/lib/jakarta-tomcat-4.1.18/bin/bootstrap.jar
  -Dcatalina.base=/usr/lib/jakarta-tomcat-4.1.18 -Dcatalina.home=/usr/lib/jakarta-tomcat-4.1.18
  -Djava.io.tmpdir=/usr/lib/jakarta-tomcat-4.1.18/temp org.apache.catalina.startup.Bootstrap  stop

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

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

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

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

注意

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

Java実行ファイル

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

wrapper.java.command=/opt/IBMJava2-131/bin/java

Java引数

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

Tomcat コマンドラインは、そのようなプロパティがいくつかあります: (注意: 最初の行は、説明のために包含されています。 実際には、スペース(空白)のない一行ライン表示です):

wrapper.java.additional.1=-Djava.endorsed.dirs=/usr/lib/jakarta-tomcat-4.1.18/bin:
  /usr/lib/jakarta-tomcat-4.1.18/common/endorsed
wrapper.java.additional.2=-Dcatalina.base=/usr/lib/jakarta-tomcat-4.1.18
wrapper.java.additional.3=-Dcatalina.home=/usr/lib/jakarta-tomcat-4.1.18
wrapper.java.additional.4=-Djava.io.tmpdir=/usr/lib/jakarta-tomcat-4.1.18/temp

クラスパス

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

wrapper.java.classpath.1=/usr/lib/jakarta-tomcat-4.1.18/common/lib/wrapper.jar
wrapper.java.classpath.2=/opt/IBMJava2-131/lib/tools.jar
wrapper.java.classpath.3=/usr/lib/jakarta-tomcat-4.1.18/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]ヘルパークラスを使っているときには、 [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 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

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

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

注意

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

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

ライブラリーパス

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

wrapper.java.library.path.1=/usr/lib/jakarta-tomcat-4.1.18/common/lib

全部をまとめる

全部をまとめると、下記のようになります: (注意: 最初の追加パラメーターの行は、説明のために包含されています。 実際には、スペース(空白)のない一行ライン表示です):

wrapper.java.command=/opt/IBMJava2-131/bin/java

wrapper.java.additional.1=-Djava.endorsed.dirs=/usr/lib/jakarta-tomcat-4.1.18/bin:
  /usr/lib/jakarta-tomcat-4.1.18/common/endorsed
wrapper.java.additional.2=-Dcatalina.base=/usr/lib/jakarta-tomcat-4.1.18
wrapper.java.additional.3=-Dcatalina.home=/usr/lib/jakarta-tomcat-4.1.18
wrapper.java.additional.4=-Djava.io.tmpdir=/usr/lib/jakarta-tomcat-4.1.18/temp
                        
wrapper.java.classpath.1=/usr/lib/jakarta-tomcat-4.1.18/common/lib/wrapper.jar
wrapper.java.classpath.2=/opt/IBMJava2-131/lib/tools.jar
wrapper.java.classpath.3=/usr/lib/jakarta-tomcat-4.1.18/bin/bootstrap.jar

wrapper.java.library.path.1=/usr/lib/jakarta-tomcat-4.1.18/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のスクリプトにより常にそのスクリプトの位置を カレント・ディレクトリーとして設定するという仕組みの利点を生かし、 また、シングル環境変数を利用することにより、上記のプロパティを変更することができるので、 プラットフォームやマシンが完全に独立する状態となりえるのです:

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

試しに動かしてみる

ここまで来れば、単純に 「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] クラスでのデフォルトでは、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のエラー・リカバリーの仕組みが正しく動作していない、ということです。





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.5.4