まず方法１は、アプリケーションの起動に［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バージョン3.0.4」を利用していますが、 バージョンの違いなどにより手順が部分的に異なる場合があります。 JBoss はルート・ディレクトリー（D:\）にインストールされています、 従ってJBossのホーム・ディレクトリーは「D:\jboss-3.0.4」となります。
Wrapperを使えるようにするために４つのディレクトリーを操作する必要があります。
まず始めに、以下のファイルをJBoss の 「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
以下のように、アプリケーション名を反映して、３つのバッチファイル名を変更します。 拡張子「.in」を外して、 ファイルの拡張子が「.bat」で終わるように変更してください。
なお、ご利用のコンピューターの設定状況によっては、拡張子が見えない場合がありますので、 拡張子が表示されるよう事前に設定を変更する必要があるかもしれません。
以下のようになるはずです：
{JBOSS_HOME}\bin\JBoss.bat {JBOSS_HOME}\bin\InstallJBoss-NT.bat {JBOSS_HOME}\bin\UninstallJBoss-NT.bat
「wrapper.exe」ファイルは、実際のWrapper実行ファイルです。 ３つのバッチファイルは、コンソールでJBossを動かすために使われ、 Windowsサービスの１つとしてJBossをインストールやアンインストールしたりすることができます。
これらのバッチファイルは、何も設定変更を必要としませんが、コンフィギュレーション・ファイル 「wrapper.conf」が 「conf」ディレクトリーにあるという前提で進めていきます。 もし、その「wrapper.conf」ファイルを他の場所に設置したい場合には、 この３つのバッチファイルの設定を適切に変更する必要があります。
以下の２つのファイルをJBossの 「lib」ディレクトリーにコピーしてください：
{WRAPPER_HOME}\lib\wrapper.dll {WRAPPER_HOME}\lib\wrapper.jar
「wrapper.dll」ファイルは、ネイティブ・ライブラリーであり、 JVM内で動作するWrapperの一部として必要なものです。 「wrapper.jar」ファイルには、全てのWrapperクラスが含まれています。
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」ディレクトリーの中に コピーしたバッチファイルを変更する必要があります。
コンフィギュレーション・ファイル「wrapper.conf」のデフォルトでは、 アプリケーション・ホーム・ディレクトリー下にある 「logs」ディレクトリーの中に 「wrapper.log」ファイルを配置します。 JBossのデフォルトでは「logs」ディレクトリーは存在しませんので、新たに作成する必要があります。 以下のようになるはずです：
{JBOSS_HOME}\logs
もし「wrapper.log」ファイルを他の場所に配置したい場合には、 「wrapper.conf」ファイルを編集して、新しい場所が反映されるように ［wrapper.logfile］プロパティを変更する必要があります。
Wapperがアプリケーションを起動できるようにWapperの設定を変更する前に、 通常使う完全なJavaコマンドを知っておく必要があります。
ほとんどのアプリケーションでは、バッチファイルを活用し、実際のコマンドラインを操作します。 一般的に、ほとんどのバッチファイルは、かなり重すぎたりで扱いにくい傾向にありますが、 実際のところ、Wrapperの優れた能力により、 それらのバッチファイルと無関係に動かすことができるのも、Wrapperメリットの一つなのです。
JBossのデフォルトでは、「bin」ディレクトリーの中にある 「run.bat」と呼ばれるバッチファイルを使ってJBossを起動します。 まずカレント・ディレクトリーを「bin」ディレクトリーへ変更して、そこから起動します。 「run.bat」をエディターで開いてみると、 ファイルの後半に下記のようなラインが表示されていることに気づくと思います。：
%JAVA% %JAVA_OPTS% -classpath "%JBOSS_CLASSPATH%" org.jboss.Main %ARGS%
大多数のスクリプトには、システム・スペック情報を収集して、 その情報を環境変数の中に格納するタスク機能を備えています。 上記の行を明記することにより、収集した全ての情報を最終のJavaコマンドへと拡張させ、 それでアプリケーションを起動させることになります。
そのバッチファイルのソースを見れば分かるとおり、 複雑なスクリプトで高機能を備えたものだと感謝してもらえたり、 複雑なスクリプトを書く面倒から完全に免れられる喜びなど、 皆様の様々な希望を叶えているものだろうと、私達は願っています。
Wrapperの設定で、本当に必要な個所は、その最後の拡張コマンドラインなのです。 スクリプト全体を読みこなしたり、理解しようと試みるよりは、 むしろ、ちょっとした簡単な小細工をしかけることで、 コンソールで最終コマンドラインを表示させることができます。 「run.bat」バッチファイルを編集して、上記の行の最初に「ECHO 」を追記してください。 そうすると、以下のようになるはずです：
ECHO %JAVA% %JAVA_OPTS% -classpath "%JBOSS_CLASSPATH%" org.jboss.Main %ARGS%
今、そのバッチファイルを再始動すると、コンソールに下記のようなものが表示されるでしょう (出力結果は全て一行で表示):
D:\Sun\j2sdk1.4.0_03\bin\java -Dprogram.name=run.bat -classpath ";D:\Sun\j2sdk1.4.0_03\lib\tools.jar;D:\jboss-3.0.4\bin\run.jar" org.jboss.Main
もし、上記のコマンドラインををWrapperで使うためには、そのコマンドラインのコンポーネントを細分化して、 コンフィギュレーション・ファイルへ落とし込んでいく必要があります。 「wrapper.conf」ファイルをエディターで開き、下記のようにプロパティに変更を加えてください。
注意
下記の文中で説明しているプロパティについて、そのリンク先では、それぞれ詳しい説明を提供しています。 じっくり時間をかけて、変更するプロパティの説明を全部、熟読してください。 多くのケースでは、ここでは触れていない事項についても、さらに詳しい使い方の説明があります。
まず、Java実行ファイルを解凍して、その配置場所のパスを ［ wrapper.java.command］ プロパティにへ割り当てます：
wrapper.java.command=D:\Sun\j2sdk1.4.0_03\bin\java
ほとんどのアプリケーションは、起動時に、JAVA実行ファイルへ、数多くのパラメーターを提供します。 Wrapperでは、クラスやライブラリーパス同様に メモリのような物事を設定するのために特別なプロパティを提供しています。 これについては後で述べますが、その他の設定は、［ wrapper.java.additional.<n> ］シリーズのプロパティを使って設定変更します。
JBoss コマンドラインは、追加的なJava引数を１つ持っています。
wrapper.java.additional.1=-Dprogram.name=run.bat
何も変更を加えずに、直接コマンドラインからフル・プロパティがコピーされていることに注目してください。 スペースを含むプロパティの扱い方について詳細は、 プロパティの説明を参照してください。
次にクラスパスです。［ wrapper.java.classpath.<n> ］プロパティを使って設定を変更します。 Wrapperでは、クラスパスを個別のエレメンツへ細分化する必要があります。 さらに、Wrapperも使っているので、「wrapper.jar」ファイルも同様に含める必要があります：
wrapper.java.classpath.1=D:\jboss-3.0.4\lib\wrapper.jar wrapper.java.classpath.2=D:\Sun\j2sdk1.4.0_03\lib\tools.jar wrapper.java.classpath.3=D:\jboss-3.0.4\bin\run.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は、ネイティブ・ライブラリーを利用します。 このライブラリー・ファイル「wrapper.dll」は、JVMへ供給されるライブラリーパスで指定しておく必要があります。 JBoss では、ネイティブ・ライブラリーを一切持ちません、 仮にあったとしても、 それがどこに位置するのかライブラリーの配置場所（ディレクトリー）を指定しておく必要があるでしょう。 ライブラリーパスは、［ wrapper.java-library-path.<n> ］プロパティを使って設定します。
wrapper.java.library.path.1=D:\jboss-3.0.4\lib
全部をまとめると、下記のようになります：
wrapper.java.command=D:\Sun\j2sdk1.4.0_03\bin\java wrapper.java.additional.1=-Dprogram.name=run.bat wrapper.java.classpath.1=D:\jboss-3.0.4\lib\wrapper.jar wrapper.java.classpath.2=D:\Sun\j2sdk1.4.0_03\lib\tools.jar wrapper.java.classpath.3=D:\jboss-3.0.4\bin\run.jar wrapper.java.library.path.1=D:\jboss-3.0.4\lib wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp wrapper.app.parameter.1=org.jboss.Main
これらの設定をしたマシンが正常に動作していることからも分かるように、 ディレクトリー構造やプラットフォームに非常に高く依存してることに注目してください。 Wrapperが作業ディレクトリーを常に 「wrapper.exe」ファイルが 存在する場所に設定するという仕組みの利点を生かし、 また、シングル環境変数を利用することにより、上記のプロパティを変更することができるので、 プラットフォームやマシンが完全に独立する状態となりえるのです：
wrapper.java.command=%JAVA_HOME%/bin/java wrapper.java.additional.1=-Dprogram.name=run.bat wrapper.java.classpath.1=../lib/wrapper.jar wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar wrapper.java.classpath.3=./run.jar wrapper.java.library.path.1=../lib wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp wrapper.app.parameter.1=org.jboss.Main
（参照：サポートされているWindowsバージョン）
最後のステップでは、［ Windows サービス・プロパティ ］の設定です。 ここでは変更すべきプロパティだけを取り上げます。 他にもいくつか有効なことはありますので、詳しくはそれぞれの使い方の説明を参照してください。 この変数の推奨された値は以下のとおりです。
wrapper.ntservice.name=JBoss wrapper.ntservice.displayname=JBoss Application Server wrapper.ntservice.description=JBoss Application Server
ここまで来れば、単純に 「bin\JBoss.bat」バッチファイルを実行することで JBossを動かすことができます。 Wrapperがカレント・ディレクトリーを設定してくれるお陰で、 「bin」ディレクトリー内部から、このバッチファイルを実行する必要はありません。 アプリケーションをサービスの一つとして動かしてみる前に、 コンソール・アプリケーションとして動かしてみて、設定が有効になっているか確認してください。
おめでとう！あなたのアプリケーションが起動して動き始めるはずです。
もし何か問題があった場合、トラブルシューティングをご覧いただき、 問題点を追及していくのに役立つことでしょう。
［WrapperSimpleApp］クラスのデフォルトでは、２秒間待機して、 ユーザー・アプリケーションのメイン・メソッドの確立を待ちます。 その後、アプリケーションがスタートしたものとして解釈して、Wrapperプロセスに戻ります。 これは、多くのユーザー・アプリケーションが 応答を返してこないメイン・メソッドで書かれているため、そのように処理を進めています。 そのようなケースでは、アプリケーションが無事にスタートアップしたのか、 スタートアップが完了したのか言及できず、 ［WrapperSimpleApp］クラスにとっては頼れる手段がありません。
しかしながら、もし、アプリケーションのメイン・メソッドが、 アプリケーションの開始応答を一旦戻してくる場合には、 Wrapperにとっては理想的なことであり、Wrapperは継続せず、 アプリケーションの起動が確立するまで待機します。
このように応答を返してくるメイン・メソッドに対しては、 ［WrapperSimpleApp］が ［org...WrapperSimpleApp.waitForStartMain］システム・プロパティを探し、 もし「TRUE」に設定されていた場合、 ［WrapperSimpleApp］ は アプリケーションのメイン・メソッドが完了するまで無期限に待機します。
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=TRUE
タイムリーなマナーでメイン・メソッドが応答を返してくることが確実に分かっている場合には、 この『無期限の待機』のオプション設定は有意義な選択肢となるでしょう。 しかし、スタートアップ・プロセスでどんなに時間がかかろうが、 Wrapperは待機中に決してギブアップすることはなく、ひたすら待ち続けるでしょう。 もしスタートアップでハングアップする可能性を考えると、 その［org...WrapperSimpleApp.maxStartMainWait］ システム・プロパティのオプション設定で「待機時間のタイムアップ最大時間」を設定しておくのが良いと思います。 スタートアップ・メイン・メソッドの起動確立に５分間まで待機させるには、 以下のようにプロパティに「300」（秒数）と設定してください (デフォルト値２秒):
wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.maxStartMainWait=300
多くのアプリケーションのメイン・メソッドでは応答を返してこない設計になっています。 その場合、デフォルト２秒のスタートアップのタイムアウトをそのまま利用するか、 あるいは、アプリケーションのスタートアップにかかる時間数を測定して、 やや長めのタイムアウト時間を［maxStartMainWait］プロパティを使って指定するか、 どちらかを必ず選ばなくてはなりません。
警告
スタート・メソッドが応答を返してこないアプリケーション用に、 ［waitForStartMain］を「TRUE」に設定した場合、 Wrapperは一見、正しく動作しているように見えるかもしれませんが、 実はWrapperは永遠に待機状態であり、決して稼働状態に入ることはないでしょう。 つまり、これは、Windowsサービス・マネージャー や、 いくつかのWrapperのエラー・リカバリー・メカニズムが正しく動作していない、ということです。
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.
