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

方法１ - WrapperSimpleApp インテグレーション (Linux / UNIX)

概要

まず方法１は、アプリケーションの起動に ［WrapperSimpleApp］ ヘルパークラスを使う手法です。 これは遥かに簡単なインテグレーション方法で、利用が可能であれば、一番お薦めの手法です。

この方法を利用するにおいて理解しておくべき点がいくつかあります。 WrapperがJVM（Javaバーチャルマシン）をシャットダウンする際に、直接アプリケーションへシャットダウンをリクエストするわけではなく、 JVM内部から［System.exit()］メソッドを呼び出してJVMのシャットダウン・シーケンスに入ります。 もし、アプリケーションが シャットダウン・フック に登録されている場合、 通常どおりに実行処理され、アプリケーションがキレイにシャットダウンできる時間を確保します。 その一方、もしシャットダウン・フックに登録されていない場合、 コンソール（コマンド・ウィンドウ）から［CTRL］＋［C］のキー操作によるアプリケーション任意停止と同じように動作し、 アプリケーションを直ちに終了させます。シャットダウン・フックの有無に関わらず、 いずれのケースでも、Wrapper導入前の環境状態と同じように動作します。

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

アプリケーションのメイン・クラス名を引き渡すことで、どのようにアプリケーションを起動するのか、 ［WrapperSimpleApp］へ指示が渡され、 ［WrapperSimpleApp］のメイン・メソッドへの その他の追加的なアプリケーション・パラメーターが続き、進んでいきます。

操作方法の詳細

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

JBossをインストールする

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

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

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

注意

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

「bin」ディレクトリー

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

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

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

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

{JBOSS_HOME}/bin/jboss

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

APP_NAME="jboss"
APP_LONG_NAME="JBoss Application Server"

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

注意

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

「lib」ディレクトリー

以下のネイティブ・ライブラリー・ファイルをJBossの次のディレクトリーにコピーしてください。 32ビット版のJBossやWrapperを利用する方は「bin/native/lib」へ、 64ビット版のJBossやWrapperを利用する方は「bin/native/lib64」へ、 コピーしてください： 

{WRAPPER_HOME}/lib/libwrapper.so

注意

JBossバージョン6で、HornetQ Projectを初期化しています。 それゆえに、２つの「bin/native/lib*」ディレクトリーが存在します。 （JBossのそれ以前のバージョンには、そのような２つのディレクトリーはありません） この場合、JBossの「lib」ディレクトリーへ ネイティブ・ライブラリー・ファイルをコピーしてください。

さらに、「wrapper.jar」ファイルも JBossの「lib」ディレクトリーへコピーしてください： 

{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」ディレクトリーです。 JBossのデフォルトでは「conf」ディレクトリーは存在しませんので、新たに作成する必要があります。 以下の設定ファイル・テンプレート「wrapper.conf.in」を JBossの「conf」ディレクトリーにコピーしてください： 

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

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

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

{JBOSS_HOME}/conf/wrapper.conf

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

「logs」ディレクトリー

コンフィギュレーション・ファイル 「wrapper.conf」 のデフォルトでは、アプリケーション・ホーム・ディレクトリー下にある 「logs」ディレクトリーの中に 「wrapper.log」ファイルを配置します。 JBossのデフォルトでは「logs」ディレクトリーは存在しませんので、 新たに作成する必要があります。

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

{JBOSS_HOME}/logs

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

「lang」ディレクトリー

Wrapperバージョン3.5.0から、 Wrapperをローカライズすることができます。 「lang」ディレクトリーに 言語リソース・ファイルがあります。 JBossにはデフォルトでそのようなディレクトリーが存在しませんので、 自分で「lang」ディレクトリーを作成して、 その中に言語リソース・ファイルをコピーしてください： 

{JBOSS_HOME}/lang/wrapper_XX.mo
{JBOSS_HOME}/lang/wrapperjni_XX.mo

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

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

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

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

JBossのデフォルトでは、「bin」ディレクトリーの中にある 「run.sh」と呼ばれるスクリプトを使ってJBossを起動します。 まずカレント・ディレクトリーを「bin」ディレクトリーへ変更して、そこから起動します。 「run.sh」をエディターで開いてみると、 ファイルの後半に下記のようなラインが表示されていることに気づくと思います。： 

    # Execute the JVM in the foreground
      eval \"$JAVA\" $JAVA_OPTS \
         -Djava.endorsed.dirs=\"$JBOSS_ENDORSED_DIRS\" \
         -classpath \"$JBOSS_CLASSPATH\" \
         org.jboss.Main "$@"
      JBOSS_STATUS=$?

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

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

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

    # Execute the JVM in the foreground
     echo eval \"$JAVA\" $JAVA_OPTS \
         -Djava.endorsed.dirs=\"$JBOSS_ENDORSED_DIRS\" \
         -classpath \"$JBOSS_CLASSPATH\" \
         org.jboss.Main "$@"

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

eval "/usr/lib/jvm/java-6-openjdk/bin/java" -server -Xms128m -Xmx512m
-XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dprogram.name=run.sh 
-Djava.library.path=/usr/lib/jboss-6.0.0.Final/bin/native/lib 
-Djava.endorsed.dirs="/usr/lib/jboss-6.0.0.Final/lib/endorsed" 
-classpath "/usr/lib/jboss-6.0.0.Final/bin/run.jar:/usr/lib/jvm/java-6-openjdk/lib/tools.jar"
org.jboss.Main

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

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

注意

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

環境変数：

コンフィギュレーション設定を容易にするために、 JbossとJavaのHOMEディレクトリーの 環境変数を設定して、 その変数をコンフィギュレーション・ファイルに書き込むことを推奨します。 これで、コンフィギュレーション・ファイルが読みやすくなり、 さらにディレクトリー・パスの変更などのメンテナンスにも好都合です。 一旦設定すると、毎回の起動ごとに環境変数を設定します。 

set.JBOSS_HOME=/usr/lib/jboss-6.0.0.Final
set.JAVA_HOME=/usr/lib/jvm/java-6-openjdk

Java実行ファイル

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

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

Java引数

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

JBoss 6.0.0.最終コマンドラインには既に８つのJava引数が追加されています。 

wrapper.java.additional.1=-server
wrapper.java.additional.2=-XX:MaxPermSize=256m
wrapper.java.additional.3=-Dprogram.name=run.sh
wrapper.java.additional.4=-Djava.endorsed.dirs=%JBOSS_HOME%/lib/endorsed
wrapper.java.additional.5=-Dorg.jboss.resolver.warning=true
wrapper.java.additional.6=-Dsun.rmi.dgc.client.gcInterval=3600000
wrapper.java.additional.7=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.8=-Djava.net.preferIPv4Stack=true

JVMの初期メモリや最大メモリ・サイズは「-Xms128m (初期)」「-Xmx512m (最大)」で指定されていますが、 ［wrapper.java.initmemory］プロパティや ［wrapper.java.maxmemory］プロパティを使って定義することができます。 

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512

注意

JBossバージョン６では、org.jboss.system.server.jmx.MBeanServerBuilderImpl をベースにしたMBeanServer Factoryを内部的に初期化していますが、これはデフォルトの JVM MBeanServerBuilder（javax.management.MBeanServerBuilder）と互換性がありません。 そのため、通常、Wrapperが開始するとき、JVMのデフォルトMBeanServerを使い、MBeanServerを作成し、 JBossが開始するとき、そのMBeansをMBeanServerへ登録するようにします、 ですが、JVMのデフォルトMBeanServerとの互換性の都合で、JBossがMBeanの登録失敗になるでしょう。 もしWrapperから提供されたMBeansを必要としない場合、 この非互換に関する問題の簡単な回避策として、 Wrapper側のMBeansを停止させることです、つまりMBeanServerの作成です。 無効にする方法は、次のプロパティを以下のように設定します： 

wrapper.java.additional.9=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false

JBossバージョン６以前では、自身のMBeanServer Factoryを実装しているため、このような「無効にする」設定は不要です。

もしJBossバージョン6.*を実行していて、WrapperのMBeansを利用したくない場合、 次のJMXガイドの説明を参照してください。

何も変更を加えずに、直接コマンドラインからフル・プロパティがコピーされていることに注目してください。 スペース（空白）を含むプロパティの扱い方については、プロパティの説明を参照してください。

クラスパス

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

wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
wrapper.java.classpath.2=%JBOSS_HOME%/bin/run.jar
wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar

メイン・クラス

JBossを起動するために使われるコマンドの最後のコンポーネントは、 メイン・クラス［org.jboss.Main］です。 起動時にJavaによって実行されるこのメイン・クラスは、 ［wrapper.java.mainclass］ プロパティを使って指定します。 しかしながら上記で述べたように、 JBoss メイン・クラスは、 Wrapperとどのようにコミニケーションを取ればいいのか分からないので、 メイン・クラスを［WrapperSimpleApp］の完全なフル・クラス名で設定します。 JBoss メイン・クラスは、次のとおり最初のアプリケーション・パラメーターとして指定します。 

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

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

アプリケーション・パラメーターは、 ［wrapper.app-parameter.<n>］ プロパティを使って設定します。 アプリケーション・パラメーターは、メイン・クラスの後、Javaコマンドラインに直接表示されます。 JBoss が何もそのようなパラメーターを持っていないうちは、これらのプロパティの一つを設定する必要がります。 その理由は、［WrapperSimpleApp］ヘルパークラスを利用しているためであり、 上記で述べたように、その最初のパラメーターは実行しているアプリケーションのメイン・クラス名なのです。 現在の例では、「org.jboss.Main」です： 

wrapper.app.parameter.1=org.jboss.Main

ライブラリーパス

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

JBossバージョン6では、 32ビット/64ビットごとに対応した「bin/native/lib*」ディレクトリーに HornetQからのネイティブ・ライブラリーを持っています。 「libwrapper.so」ファイルが既にコピーされているはずですので、 １つの定義が必要です。 もし他のネイティブ・ライブラリー・ファイルを使っている場合、 それに続き、順序良く定義する必要があるかもしれません。 ライブラリーパスは、 ［wrapper.java-library-path.<n>］ プロパティを使って設定します。 

#For 32-bit architectures
wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib
#For 64-bit architectures
#wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib64

それ以前のJBossバージョンでは、「%JBOSS_HOME%/lib」ディレクトリーを使ってください。

全部をまとめる

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

set.JBOSS_HOME=/home/christian/tanuki/jboss.6.final/jboss-6.0.0.Final
set.JAVA_HOME=/usr/lib/jvm/java-6-openjdk

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

# Java Main class.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)
wrapper.java.classpath.1=%JBOSS_HOME%/bin/run.jar
wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.3=%JBOSS_HOME%/lib/wrapper.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
#For 32-bit architectures
wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib
#For 64-bit architectures
#wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib64

# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE

# Java Additional Parameters
# JVM settings
wrapper.java.additional.1=-server
wrapper.java.additional.2=-XX:MaxPermSize=256m
wrapper.java.additional.3=-Dprogram.name=run.sh
wrapper.java.additional.4=-Djava.endorsed.dirs=../lib/endorsed
wrapper.java.additional.5=-Dorg.jboss.resolver.warning=true
wrapper.java.additional.6=-Dsun.rmi.dgc.client.gcInterval=3600000
wrapper.java.additional.7=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.8=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.9=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main

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

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

wrapper.java.additional.1=-Dprogram.name=run.sh

wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=./run.jar
wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar

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

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

wrapper.app.parameter.1=org.jboss.Main

試しに動かしてみる

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

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

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

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

上級者向け

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

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

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

waitForStartMain システム・プロパティ：

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

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

maxStartMainWait システム・プロパティ：

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

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

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

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

注意

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

警告

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

Copyright (c) 2004-2011, Tanuki Software, Ltd. All Rights Reserved.