デフォルトでは、SYSTEMユーザーとしてWindowsサービスを動作させます。 この「ネットワーク・ドライブにアクセスできない」問題の原因は、SYSTEMユーザーは、ネットワーク・リソースにアクセス権がありません。 もし、アプリケーションがWindowsサービスとして正常に動作しているならば、 まず最初に試してみることは、コンソール・アプリケーションとして正常に動作する時と 同じユーザーでログインして、サービスを動かしてみることです。

その手順を説明すると、

• まず始めに、もし現在、Windowsサービスの１つとして動作している場合には、そのアプリケーションをアンインストールしてください。
• その後、「wrapper.conf」ファイルをエディタで開き、 ［wrapper.ntservice.account］プロパティ と ［wrapper.ntservice.password］プロパティ を設定してください。
• その後、再インストールしてサービスとして動作させます。

そうすると、現在、サービスは、コンソール・アプリケーションとして動作しているのと同じ環境で動いていますので、 全てが問題なく正しく動作するはずです。

セキュリティの都合で、特にこのサービス用に、新しいユーザーを作成および設定を希望する方も多いでしょう。

一部のシステム上では、システムの再起動時に、 本当のユーザーが実際にログインして、そのドライブへ接続するまで、 ドライブ・レター（ドライブを示すアルファベット）を割り当てられたドライブが、 常にアクセス可能というわけではないようです。 この問題の回避手段としては、ドライブ・レターではなく、 ドライブを直接的に参照するUNC形式（マシン名を含むフルパス）を使うことです。

//host/share/path

Java Service Wrapperは、直接的には実行可能な「jar」ファイルをサポートしていません。 しかし、簡単な回避手段があります。

まず始めに、JVMが「jar」ファイルを動かすときに、実際に実行されるクラスを確認してください。 その確認方法は、「jar」ファイルのコンテンツを「temp」ディレクトリーに展開する必要があります。 「jar」ファイルは、単なる圧縮ZIPファイルですので、 お手持ちのZIPユーティリティやJavaに付随する「jar」ファイルのユーティリティをご利用ください。

「jar」ファイル内に、 「meta-inf/Manifest.mf」ファイルが見えるはずです。 そのファイルをエディタで開き、次のように明記します：

Manifest-Version: 1.0
Main-Class: com.myco.myapp.Main

単純に「-jar」パラメーターや「jar」ファイルを Javaへ引き渡すことで、上記のメイン・クラス名を読ませ、アプリケーションを動かすようにできます。 ですから、Wrapperに同じアプリケーションを起動させるようにするには、 他のjarファイル同様に、Wrapperクラスパス上の実行ファイルjarを含めさえすれば良く、 アプリケーションのメイン・クラスとして、「Main-Class」を使って、 通常のインテグレーション手順どおりに進めてください。

［CTRL］＋［BREAK］や［CTRL］＋［\］のキー操作、あるいは、API経由で、スレッド・ダンプを要求すると、 ログに次のようなメッセージが表示され、JVMが再起動します：

wrapper  | JVM exited unexpectedly.

まず、JVMを起動する際に、［-Xrs］フラグを指定していないことを確認してください。 このフラグは、Wrapperを使わずにJavaを動かす環境では便利ですが、 様々なシステム・シグナルに応答できるようにするために、Wrapperの能力を下げて互換モードで動作することになります。

Wrapperの設定で、システム・シグナルを無視するJVMにするには、 代わりに［wrapper.ignore_signals］ プロパティをご利用ください。設定を変更する際には、必ず最初に説明を読んでください。

WrapperでCOMアプリケーションを動かそうとすると、問題が起きるという報告も数例あがっています。 アプリケーションがスタンドアローンとして単独で正常に動作する場合でも、 Wrapperで動かそうとすると、次のようなエラーが出る場合があります：

Caught java.lang.NullPointerException: name can't be null while loading driver com.sun.comm.WindowsDriver

COM API には２つのファイルを有効にする必要があります： ライブラリーパスの「win32com.dll」ファイルと、 ［system.getProperty("java.home")］によって返されるディレクトリーの サブディレクトリー「lib」に配置された 「javax.comm.properties」プロパティ・ファイルです。

自分の「wrapper.conf」ファイルが ［JAVA_HOME］環境変数によって指定されているものとは異なるJVMを使うように設定されているような場合に、 このような問題が発生します。自分の「wrapper.conf」ファイルで、 下記のように［wrapper.java.command］プロパティで 正しく設定されてたJVMを利用していることを確認してください。

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

Wrapperの導入前と導入後（インテグレーション後）のJavaアプリケーションの動作環境で唯一の違いは、 スタートアップ時にJVMによって直接的にアプリケーションのメイン・メソッドが呼び出される前の部分です。 ［WrapperSimpleApp］ヘルパークラスや ［WrapperStartStopApp］ヘルパークラスを 利用していることを確認してください。 JVMは、まず始めにクラスのメイン・メソッドを呼び出し、その後、Wrapperが初期化してから、 アプリケーションのメイン・メソッドを呼び出します。

これは、セキュリティ・マネージャーを利用している際に、問題を引き起こすことがあります。 その理由は、Java セキュリティ・マネージャーがコール・スタックを検索して、アクセスを認める前に、 各クラスやメソッドに保護されたコードを呼び出す権利が与えられてるということを確認しているためです。 Wrapperのクラスがコール・スタックを終了して特権を与えられていないと、 セキュリティ例外を受けることになります。

ポリシーファイルに以下のように「wrapper.jar」にパーミッション（アクセス権限）を追加してみてください。 通常であれば、この種の問題は改善されるはずです。：

// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
    permission java.security.AllPermission;
};

一部のJava サービス・アプリケーションでは、 「Windows上でユーザーがログアウトすると、Javaプロセスを終了してしまう」という問題がたまにあります。 Wrapperで初代リリースの時点から、この問題に影響されることなく、適切に対処しています。

WrapperのJava側は、この問題を正しく動かすために、 ネイティブ・ライブラリー （Windows：「wrapper.dll」、Linux/UNIX：「libwrapper.so」） を必要としています。 ネイティブ・ライブラリーは、 全てのシステム・シグナルがJVMプロセスへ送ったり、それらを正しく取り扱ったり、などの 完全遂行を担っています。 Javaアプリケーションによっては、 ［WrapperListener］ インターフェイスの ［controlEvent］ メソッドを実装することで、これらのシグナルを取り扱いが可能になる場合もあります。

ユーザーのログオフ時に、WrapperによってJVMが再起動されるという問題に悩んでいる場合には、 ライブラリーがロード（読み込み）されていることを確認してください。 もしロード（読み込み）されていない場合、WrapperManagerの初期化中に、警告メッセージがJVM出力に表示されます。

Wrapperがコンソール・アプリケーションとして、または、サービスとして、動作している間に、 ユーザーがログアウトすると、何が起きるかの例は、TestWrapperアプリケーションセクションを参照ください。

Windowsシステムの場合、「wrapper.conf」ファイル の［wrapper.ntservice.process_priority］プロパティ を設定することで優先度を設定できます。 詳しくは、コンフィギュレーションの概要をご覧ください。

UNIXシステムの場合、 優先度の設定のおススメの方法は、Wrapper起動時に、 ご自分のシェルスクリプトにある「nice」コマンドを使うことです。 Wrapperに同梱されたスクリプト例では、どのようにしたらいいか、を説明しています。 「nice」の使い方についての詳細は、 「man nice」 あるいは、 「info nice」をご覧ください。

Wrapperのデフォルトでは、JVMのユーザーディレクトリーとして、 Windowsでは「wrapper.exe」ファイルのある場所、 UNIXシステムでは「Wrapper シェルスクリプト」のある場所、 を設定します。 これにより、アプリケーション内で、信頼性を高く、相対パスを使えるようにします。 ユーザーディレクトリーはJVMが起動する場所に依存するため、通常は可能ではありません。

相対パスを利用することで、 いかなるディレクトリー内へでもアプリケーションを解凍し、確実に動かすことができるので、 非常に簡単にアプリケーションをインストールできるようになります。

デフォルト以外の場所にユーザーディレクトリーを設置する必要があるケースもあります。 その場合には、 ［wrapper.working.dir］プロパティを設定することで 変更が可能です。

Windowsで複数のWrapperを動かしている時、タスク・マネージャーには、 全て「wrapper.exe」や「java.exe」と表示されているため、 どれがどのアプリケーションなのか識別するのは困難です。 Windowsのセキュリティ上の理由のため、表示名を変更する機能をWrapperに実装することは不可能です。

この回避策として、ややハッキングっぽい手荒な方法ですが、効果的です。 「wrapper.exe」ファイル名を「wrapper-myapp.exe」に変更します。 その後、バッチファイルを変更して、 この新しい「wrapper-myapp.exe」を利用できるように設定します。

Javaプロセスにも、同じように手を加える必要があります。 「%JAVA_HOME%/bin」ディレクトリーへ行き、 「java.exe」を複製して「java-myapp.exe」を作成します。 その後、「wrapper.conf」ファイルを変更して、 この新しい「java-myapp.exe」を利用するように設定します。 この新しい「java-myapp.exe」を利用できるように設定します。

Windowsタスク・マネージャーを見ると、どの実行ファイルが動作しているのか、簡単に確認することができます。

「wrapper.conf」ファイルで、 ［wrapper.pidfile］プロパティや、 ［wrapper.java.pidfile］プロパティを設定することもできます。 そうすると、PIDを含むファイルが作成されます。 タスク・マネージャー上で、そのPIDが表示されるので識別が可能になるでしょう。 プロセスPIDを表示するように、タスク・マネージャーの設定を変更する必要がありますのでご注意ください。

Windows上では、［wrapper.ntservice.account］ プロパティを設定することで、特定のユーザーとしてWrapperを動かすことができます。 その説明を熟読してから、サービスを再インストールしてください。

UNIX上では、Wrapperシェルスクリプト(src/bin/sh.script.in)で「RUN_AS_USER」変数を設定します。 ［console］コマンドで動作中には、Wrapperはカレント・ユーザーとして動作しますが、 ［start］コマンドで動かす場合、指定されたユーザーへ変更して、Wrapperを起動します。 つまり、カレント・ユーザーは「ユーザー変更」の権限を持っている必要があります。

もし、JavaアプリケーションがWindowsサービスとして動作しているならば、 それは実際にはVisual VMを起動しているユーザーと同じコンテキスト／セッションで動作していません。 従って、デフォルトで、Visual VMはJavaアプリケーションを見つけることができません。

Windows XPまでは、Windowsサービス用のlaxセキュリティ・ポリシーによって、 次のステップのように、かなり簡単に解決を可能にしていました：

JVMが開始している時点で、JVMはそのプロセスを書き込んでいて、 環境変数「%TMP%」で指定された配置場所へ情報をフックしています。 一部の（ここのを含む）環境変数が各ユーザー用に別々に定義されていることを念頭に置いておいてください。 そのため、２つのプロセス（自分のアプリケーションとVisualVM）がこの環境変数を同期する必要があります。

set.TMP=C:\tmp

その後、サービスを（再）起動してください。 次に、ここでコンソールを開始して、「TMP」環境変数を上記のコンフィギュレーション・ファイルで指定した同じ値に設定してください：

set TMP=C:\tmp
C:\Program Files\...\jvisualvm.exe

Visual VM はJavaプロセスを一覧にすることができるはずです。

Windows XPまではWindows版用に上記が動作していましたが、 Windows Vista／7 （さらに後続版）は、より厳しくなったセキュリティ測定のため、 ほとんど誰にも許可しないでしょう。そのため、これを解決する唯一の方法は、 JMXリモート・モニタリング設定（必要要件：最低でもJava1.5）を利用することです。

wrapper.java.additional.N=-Dcom.sun.management.jmxremote.port=XXXX
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.authenticate=false

［wrapper.java.additional.<n>］プロパティで 未使用の番号「N」を利用して、ご利用のマシン上で「XXXX」を未使用ポート番号で置き換えてください。 VisualVMから［ファイル］→［JMX接続を追加する］を選択してください。 ［接続］フィールドで、「localhost:XXXX」（XXXXはconfファイルで割り当てたポートです）を入力してください。