Java Service Wrapperを使うと、 JavaアプリケーションをWindowsサービスの１つとして組み込む（インストールする）したり、 同様に、Wrapperに同梱して提供しているスクリプトを使うと、Unix システム上のデーモン・プロセスとして、 Javaアプリケーションを簡単に組み込む（インストールする）ことができます。

Wrapperは、Windowsの環境下で、デスクトップと相互に影響するサービスを走らせる能力、 サービスの依存性、ユーザーのログアウトを正しく取り扱います。

Javaの拡張した利用により、 皆さんのアプリケーションは、様々なミッションや重要なサービスを提供するために書かれています。 それらのサービスは、ハイレベルの信頼性を提供できることが不可欠です。 理想の世界では、１００％のバグなしのソフトウェアだけがリリースされればと願うものです。 しかしながら、これまでの過去の履歴を見ても、そうでもないようです。 ほとんど全てのアプリケーションは、ある時点では品質の問題、別の時点では動作状況の問題など悩まされ、 アプリケーションは、ハングアップしたり、クラッシュしたり、メモリ不足になったり、あらゆる問題を抱えています。 可能な限り、重要なサービスを停止させることなく、問題は素早く改善されるべきでしょう。 しかしながら、問題の解決に驚くほど高額なコストがかかったり、 短時間での問題解決は不可能であったりすることも多々あります。

Wrapperは、JVM（Javaバーチャルマシン）プロセスをモニタリング（監視）し、 もしJVMがクラッシュしたり、ハングアップした時には、自動的に再起動させます。 この処理は、Wrapperが「問題がある」と判断した場合に実行され、所要時間はほんの数秒です。 さらに、JVMのコンソール出力を監視して、JVMを再起動したりシャットダウンする際に、 ある一連の文字列に反応して動くように、Wrapperの設定を変更することもできます。

Java Service Wrapperが高機能と言えども、これだけで全ての問題を取り除くことはできないでしょうが、 問題が発生した場合でも、あなたがオフィスに入ってログをチェックするまで、少なくとも、 Wrapperが代わりに、物事を動かし走らせてくれることを知っていれば、十分に安眠を得られることでしょう。 緊急の呼び出し電話にサヨナラをいいましょう！

一度コンフィギュレーションを設定すれば、どこでも動く。 Javaは『Write Once, Run Everywhere（一度プログラムを書けば、どこでも動作する）』プログラミング言語として、 市場に出回っています。 アプリケーションの多方面から見ると、これは確かに真実なのですが、 ディべロッパー（開発者）は、しばしば苦悩に立たされ、クラスパスの構築を駆使したり、 アプリケーションを起動するのに必要なシステム情報を収集したり、 プラットフォーム特有に合わせた複雑なスクリプトを書かなければならない現実があります。

Java Service Wrapperは、幅広い多種多様のプラットフォーム用のスクリプトをパッケージにして提供することで、 ディべロッパー（開発者）を苦悩から解き放つお手伝いをします。 そのスクリプトを使えば、ほぼどんなJavaアプリケーションでもWrapperでコントロールし、起動させることができます。

Wrapperは、全てのJVM （Javaバーチャルマシン）コンフィギュレーションを プラットフォームの独立型コンフィギュレーション・ファイル 「wrapper.conf」（設定ファイル）へ移管します。 詳しくは、『インテグレーション方法の概要』にある事例をご覧ください。

Java Service Wrapper は、JavaアプリケーションへJVM（Javaバーチャルマシン）を 再起動するようにリクエストを出す手法を提供しています。 これは多くのケースで便利で、 アプリケーションがコンフィギュレーション・ファイル（設定ファイル）を変更した後、再起動が必要かもしれません、 あるいは、メモリやリソース漏れなどの類の問題を回避するために、単にアプリケーションの再起動が必要かもしれません。

JVM 再起動には、 ［WrapperManager.restart()］ を呼び出すことで、JVM内部から引き起こすことができます。 さらに詳しくは、『JavaDocs』セクションの ［WrapperManager.restart()］をご覧ください。

再起動のキッカケを引き起こすための、もっと受動的な手法もいくつかあります。 Wrapperは、あるテキストが検知されるたびに、いつでもシャットダウンや再起動を引き起こす コンソール出力のモニタリング（監視）機能を備えています。

他のJVM インスタンスの再起動、あるいは、 通常はJVMによって戻される終了コードに依存するシャットダウン、 どちらでもWrapperを設定することができます。

Java Service Wrapper は、 JVM（Javaバーチャルマシン）設定に必要な多様なコンフィギュレーション・プロパティを提供しており、 可能な限りコマンドラインから設定することができます。 また、Wrapperコンフィギュレーション・ファイル 「wrapper.conf」（設定ファイル）は、 さらに、サービスとしてインストールされているのかWrapper状況を把握するためにログ化してみる、 などの物事の設定を可能にする多くのプロパティを提供しています。

さらに詳しくは、『コンフィギュレーション・プロパティ』をご覧いただき、 どんな事が可能なのか確認してください。 なお、コンフィギュレーション・ファイル 「wrapper.conf」 （設定ファイル）の操作に飛び込む前に、 必ず、『インテグレーション方法の概要』を熟読してください。

Wrapperの標準スクリプトやコンフィギュレーション・ファイル 「wrapper.conf」 （設定ファイル）内で 相対パスを利用することで、複雑なインストール作業を必要とせず、 ユーザーが選択したディレクトリーの中にアーカイブ・ファイルを単純に解凍すればいい程度の作業で、 アプリケーションを配置することが大抵可能です。

Java Service Wrapperは、いかなる外部の最高のログ化ツールの代替えになることはありません、 あるいは　そうするべきでないでしょう。 しかしながら、JVM（Javaバーチャルマシン）コンソールへ stdout（データ標準出力）とstderr（標準エラー出力）をどのように取り扱うかを設定できる 多くのプロパティを提供しています。 この出力は、コンソール、ファイル、イベントログ(Windows)、 "syslog"(Unix)などの、いかなる組み合わせでもログ化することができます。

JVM コンソールへの出力をログ化することは、 アプリケーションの問題を追究するには極めて重要であるはず。 Windowsでは１つのサービスとして、あるいは、Unixではデーモン として、 JVMが動作しているとき、 通常、Wrapperが動作していない状態では、そのコンソール出力は失われるでしょう。 Wrapper は確実に全てのコンソール出力をログ化していきます。

Javaベースのログ化ツールは、JVM内部から生成された出力をログ化するだの能力です。 もし、JVM がクラッシュしたり、スレッド・ダンプのようなローレベルのメッセージを表示出力したりする場合、 通常はログ化できる道はありません。 Wrapperでは、JVMクラッシュした場合でもJVMを再起動してログ記録を残していくことができ、 Wrapperは、JVMプロセスからの全てのコンソール出力をログ化します。

さらに詳しくは、『ログ化のコンフィギュレーション』をご覧ください。