一般的に、アプリケーションは Wrapper の環境下であっても、スタンドアローンの状態と同等の速度で動くはずです。 いくつかチェック項目があります。

数名のユーザーから、「wrapper.log 」ファイルに 以下のようなメッセージが表示されるという報告をいただきました：

WrapperManager: ERROR - Unable to load the Wrapper's native library because none of the
WrapperManager:         following files:
WrapperManager:           wrapper-windows-x86-64.dll
WrapperManager:           wrapper.dll
WrapperManager:         could be located on the following java.library.path:
WrapperManager:           E:\myworkspace\tortoise\wrapper\wrapper_3.5.x\professional\bin\..\lib
WrapperManager:         Please see the documentation for the wrapper.java.library.path
WrapperManager:         configuration property.

デルタパックをご利用の場合、プラットフォームに対応するライブラリが指定されたディレクトリにあることを確認してください。

問題の詳細がコンソールに表示され、 同様にログファイルにも出力されているはずです。 さらに詳しい出力を得るためには、 ご利用中の「wrapper.conf」ファイルを編集して、［wrapper.debug］プロパティを有効化（コメント記号を外す）して、デバッグを有効にしてください。 これで、アプリケーションを監視して、起動プロセスの各ステップごとに出力の詳細が表示されます。

もしアプリケーションが、Wrapper を使わない状態なら動作し、Wrapper を使うと動作しなくなる場合には、 往々にして、「wrapper.conf」ファイルの設定に誤りがあることが多いです。 Java を起動するコマンドをもう一度じっくり確認して、デバッグ出力を調べてください。 クラスパス等の設定に誤りがある可能性があります。

Wrapper が指定された Wrapper コンフィギュレーションファイルを見つけられないか、 何かの理由により、構成されたログファイルを開くことができない可能性があります。 どちらのケースでも Wrapper は、ログファイル「wrapper.log」を現在の作業ディレクトリ（カレントディレクトリ）へ出力します。 カレントディレクトリは、ほとんどの場合、 バイナリが含まれているディレクトリです。 ただし、いくつかのケースでは、Windows サービスとして実行しているとき、 「wrapper.log」ファイルは、 システムディレクトリ（WinNT\System32）に出力される場合もあります。

アプリケーション内で［System.exit()］を呼び出すと、 Wrapper はそれを検知して、キレイなシャットダウンを試みます。 もし、シャットダウンプロセス中に、 アプリケーションが再び［System.exit()］を呼び出すと、 そのコールが永久にブロックしてしまい、アプリケーションがハングアップします。 また、AWT フレーム上で、あるいは、シャットダウンフックスレッド内部からのウィンドウ上で、 ［destroy()］メソッドを呼び出すと問題が起きます。 この問題を回避する方法の詳細については、 コンフィギュレーション概要にある ［wrapper.disable_shutdown_hook］プロパティを参照してください。

この問題は、［wrapper.java.command］プロパティを、直接「java.exe」へではなく、 バッチファルへ設定していることが原因かもしれません。 スレッドダンプを要求すると、「BREAK」シグナルが Java プロセスではなく［command.exe/shell］プロセスへ送信されます。 それで、シグナルを JVM へ転送しますが、同時に、『［CTRL］＋［C］のキー操作があった』という内部フラグが設定されます。 バッチスクリプトチャイルド（子）が終了するとき、 即座にユーザーに「そのバッチスクリプトを継続したいか、あるいは停止したいか」と尋ねます。

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager デバッグ: パケット送信しました STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | wrapper  | 2009/10/23 14:30:56 | シャットダウン失敗: 終了する JVM 待ちのタイムアウト。
ERROR  | wrapper  | 2009/10/23 14:30:56 | JVM はリクエストに応じて終了しませんでした、中止しました
STATUS | wrapper  | 2009/10/23 14:30:57 | <-- Wrapper が停止しました

もし JVM 起動の前／後に、何か追加プロセスをする必要があるならば、 Java Service Wrapper プロフェッショナル版のイベントコマンド（イベントに応じたコマンド実行）設定機能をご利用ください。

この問題は、前述の問題と同類であり、同じ理由により引き起こされています。

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)

もし JVM 起動の前／後に、何か追加プロセスをする必要があるならば、 Java Service Wrapper プロフェッショナル版のイベントコマンド（イベントに応じたコマンド実行）設定機能をご利用ください。

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

JBoss バージョン 6 では、org.jboss.system.server.jmx.MBeanServerBuilderImpl をベースにした MBeanServer Factory を内部的に利用していますが、 これは、デフォルトの JVM MBeanServerBuilder（javax.management.MBeanServerBuilder）と互換性がありません。

この解決には２つの手法があります。 まず最初の手法は、Wrapper の MBeans を登録から外して無効にすることです。 詳しくは、インテグレーション方法１をご覧ください。 もう一つの手法は、JBoss が使っている MBeanServer Factory を、JVM でも使うようにすることです。 詳しくは、JMX ページをご覧ください。

wrapper  | 「C:\wrapper-windows-x86-32-3.5.7-pro\bin\wrapper.exe」に署名が見つかりましたが、一致しません: (エラーコード： 0x800b010a）
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   署名者証明: 
wrapper  |     シリアル番号： 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     発行者名: UTN-USERFirst-Object
wrapper  |     件名: Tanuki Software Ltd.
wrapper  |   タイムスタンプ証明:
wrapper  |     シリアル番号： 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     発行者名: UTN-USERFirst-Object
wrapper  |     件名: COMODO Time Stamping Signer
wrapper  |     タイムスタンプ日時 : 2010/12/19 22:32
wrapper  | Wrapper 停止します。

Wrapper バージョン 3.5.7 から、 Wrapper 全エディション（コミュニティー版、スタンダード版、プロフェッショナル版）の Windows バイナリ （例えば「wrapper.exe、wrapperW.exe、あるいは wrapper.dll」）には、 弊社タヌキソフトウェアからの純正ファイルであるか認証するコード署名が導入されています。 何か問題を検知すると、Wrapper はシャットダウンされます。

Wrapper バージョン 3.5.28 から、Wrapper は SHA-2 証明書で証明され、これまで使用されていた SHA-1 アルゴリズムよりも強力なセキュリティを提供します。 これは、2016年1月1日以降 SHA-1 のサポートを終了すると公開しましたマイクロソフトの SHA-1 廃止措置に関するポリシーに伴い変更することを決めました。

弊社の署名者 Comodo によって提供された証明書が正しくインストールされていない場合、上記のエラーが発生します。

証明書は Wrapper を作動しているアカウントがアクセスできるストアにインストールされる必要があります。 Wrapper はコンソールアプリケーションとして作動している場合、それは現在のユーザーの可能性があります。 サービスとして動かしている場合、利用しているサービスアカウントからアクセス可能である必要があります。 その代替案は、両方のモードでアクセスできるように証明書をローカルマシンにインストールすることです。

インストールされた証明書は Windows 証明書マネージャー 「certmgr.msc」（現在のユーザー）、 あるいは 「mmc」（全てのユーザー）から調べることができます。

特定のアカウントの証明書を管理するには Windows の検索ボックスから「mmc」を実行してください。 ファイルメニュで、「スナップインの追加と削除」をクリックし、「証明書」をダブルクリックしてください。 そこで「ユーザー アカウント」、「サービス アカウント」、若しくは「コンピューター アカウント」を管理する証明書を選択します。 サービスアカウントの場合、コンピューターにインストールされているすべてのサービスが表示されます。 Wrapper をサービスとしてインストールした際に使用したサービスを選択してください。

二つの証明書をインストールできます。下記に Comodo ウェブサイトより証明書をダウンロードできる URL があります。

• AddTrust External CA Root より発行された相互署名証明書（addtrustexternalcaroot.crt、comodorsaaddtrustca.crt、comodorsacodesigningca.crt）は、Wrapper のすべてのバージョンに適用している他、旧バージョンの Windows を使用している従来のデバイスとの互換性が高いです。
  https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/985/108/code-signing-sha-2

  「mmc」及び「certmgr.msc」を利用して、証明書のインストールを確認できます。

  • 「AddTrust External CA Root」は、「Trusted Root Certificate Authorities\Certificates」配下にインストールする必要があります。

  • 「COMODO RSA Certification Authority」と「COMODO RSA Code Signing」は、[中間証明機関\証明書]配下にインストールする必要があります。 署名ハッシュアルゴリズムが、使用している Wrapper のバージョンと一致することを確認してください（Wrapper 3.5.28 以降は sh384 若しくは sha-2、それ以前のバージョンは sha-1）。 これは、証明書をダブルクリックして［詳細］タブを開くことでも確認できます。 これらの証明書がコンテキストメニューからアクセスできるプロパティウィンドウで有効になっているかどうかを 確認することもできます。

  • 「UTN-USERFirst-Object」 は、［サード パーティ ルート証明書機関\証明書］配下にインストールする必要があります。

• Comodo RSA Certification authority Root (comodorsacertificationauthority.crt) は、 SHA-2 署名付きバイナリ（Wrapper バージョン 3.5.28 以降）でのみ使用できる単一の証明書です。
  https://support.comodo.com/index.php?/Knowledgebase/Article/View/969/108/root-comodo-rsa-certification-authority-sha-2

  「mmc」、或いは「certmgr.msc」を使用すると次のインストールが確認できます。

  • COMODO RSA Certification Authority により発行された「COMODO RSA Certification Authority」は、［サード パーティ ルート証明書機関\証明書］配下にインストールする必要があります。

カレント（現在の）ユーザーまたはローカルコンピュータの証明書をインストールするには単に「.crt」ファイルを実行し、 インストール手順に従います。 サービスユーザーへインポートするには、「mmc」を実行し、上記と同様にスナップインを追加し、 左パネルにあるこのスナップイン配下の一つの任意のストアを選択し（フォルダーアイコンでマークされています）、 メニューの［操作］→［すべてのタスク］→［インポート］をクリックし、 ［証明書の種類に基づいて、自動的に証明書ストアを選択する］オプションを選択してください。

それでもエラーが表示される場合は、サーバーのローカルセキュリティポリシーが厳しすぎて、証明書を検証できない可能性があります。 こちらの設定はサーバーのローカルセキュリティポリシーにあります。 Windows の実行/検索ボックスから「secpol.msc」を起動させ、［公開キーのポリシー］直下にある、［証明書パス検証の設定］をクリックします。 ポリシー設定が定義されている場合、[ストア]タブにある、「ルート証明書ストア」の［サードパーティのルート CA とエンタープライズのルート CA］にチェックが入っていることを確認してください。 これが有効にならない/できない場合、別の選択肢は「サードパーティのルート CA」フォルダーから、「UTN-USERFirst-Object Certificate」を「信頼されたルート証明機関」フォルダーへ移動させることです。

Wrapper バージョン 3.5.8 では、 カウンター署名者（副署名）の問題によるものではなく、原因は直接 Wrapper によって署名が認証できない場合にのみ Wrapper がシャットダウンします。

Wrapper バージョン 3.5.7 では、潜在的なバグがあり、 署名認証に失敗して、 Wrapper がエラー報告を送ろうとすると、アクセス違反を引き起こしていました。

Wrapper バージョン 3.5.34 から、Wrapper バイナリーは「SHA-1」および「SHA-2」ハッシュアルゴリズムで二重に署名されているため OS レベルでより強力な検証を可能にしました。 アルゴリズムとタイムスタンプを確認するのは、バイナリを右クリックし、コンテキストメニューの「プロパティ」を選択して、 「デジタル署名」タブを開いてください。

「SHA-256」ハッシュアルゴリズムは、このアルゴリズムをサポートしていない古いバージョンの Windows では表示されません。 マイクロソフト社は Windows 7 および Windows Server 2008 R2 用に「SHA-2」のサポートを追加するアップデートを公開しました。 このアップグレードが存在している場合、「SHA-2」ハッシュを検証できますが、存在しない場合は、「SHA-1」ハッシュのみを 検証することができます。 最新の Windows バージョンは「SHA-256」をサポートしているため、この更新は不要ですが、古いバージョン（Windows XP、Vista、Windows Server 2008）では「SHA-1」ハッシュのみを検証できます。

デジタル署名が有効であることを確認するには、署名リストでその署名をクリックします。

最後に、Windows XP SP2 以前や Windows Server 2003 では「SHA-2」がサポートされておらず、 新しい証明書はこれらのプラットフォームに適用されないことに注意してください。 Windows Itanium 用のバイナリも署名されなくなります。

Wrapper 自体は Comodo や他のサーバーにアクセスはしませんが、Wrapper バージョン 3.5.7 より、バイナリは Comodo 証明書でコードサイニングされています。 これは、OS が Wrapper バイナリが実際にタヌキソフトウェアのものであること確認するために重要です。

Windows がコードサイニングされたバイナリを起動するときに、先にバイナリが改ざんされていないことを確認するために バイナリをチェックして署名と一致することを確認します。 通常、バイナリを確認する際に使用される Comodo 証明書は Windows マシン上に既存していますが、場合によって、 OS はインターネットへ接続し、知られた場所からダウンロードします。 Wrapper が起動している時に接続するように見えますが、実際には開始前に接続します。 場合によって、Wrapper が接続しているように見えます。 次のサーバーへのアクセスが報告されています： ocsp.comodoca.com と a125-56.204-123.deploy.akamaitechnologies.com（Akamai サーバーの IP 部分はリクエストによって異なります。）

これはお客様へ懸念を引き起こす場合は、スタンダード版やプロフェッショナル版で Wrapper バイナリをカスタマイズ することで証明が削除されます。 ただし、そうすることで OS はバイナリの真正性を検証するが出来なくなります。

Wrapper 自体では、Windows 上で動作できる Wrapper インスタンスの数に制限をかけていませんが、 Wrapper や特に Java は、様々なリソースを消費するため、事実上、そのシステム上での動作に限界があります。 問題を引き起こしそうな、最も一般的なリソースは、デスクトップヒープです。 対処方法など詳しくは、「デスクトップヒープ問題を解決する」をご覧ください。

Java 9 は複数の引数で指定されるオプション（ --module-path や --add-modules など）を導入しました。 通常、引数はオプション名と空白スペースで区切られますが wrapper.java.additional.<n> プロパティの値に空白スペースが含まれている場合、区切り文字ではなく引数値の一部として解釈されます。 それの解決方法の一つとしてはオプション名と引数値空白スペースの代わりに等号「=」 で区切ることです。

wrapper.java.additional.1=--add-modules=MODULE1,MODULE2

これは、長いオプション（「--」で始まるオプション）でしか使用ができません。 同等の短いオプションで使用できません。 例えば、「-p=<PATH>」 は使用できません。（「-p」は「--module-path」の同等の短いオプション）。

空白スペースと同等の短いオプションの両方を利用できる別の方法とは、JDK_JAVA_OPTIONS の環境変数を利用することです。 JVM はこの変数の内容をコマンドラインのオプションに追加します。 次のシンタックスで Wrapper コンフィギュレーションファイルに設定できます：

set.JDK_JAVA_OPTIONS=--add-modules MODULE1,MODULE2

ただし、（wrapper.java.command.loglevel プロパティを使って）Java コマンドラインを出力するときに、起動時に JVM のみによって解析されるため、JDK_JAVA_OPTIONS のコンテンツを見ることができません。

長いオプションや JDK_JAVA_OPTIONS 変数の詳細については、Oracle 社のウェブサイト（英語）より確認できます。

「java.util.Random.nextLong()」や他のランダムなメソッドへコール（呼び出し）する Java アプリケーションは、 最初に呼び出すときに非常に遅くなる可能性があります。 これは、システムのエントロピー不足が原因です。 コールは、そのようなエントロピーが新たにたまり、適切な数を返せるまでブロッキングされます。 残念ながら、起動時に他に何も起こっていない場合、これには非常に長い時間がかかる可能性があり、 その間にアプリケーションはフリーズしているように見えます。

これが発生しているかどうかを検出する唯一の方法は、待機中にスレッドダンプ要求を発行することです。 もし、これが原因だった場合、すぐに分かります。

これが問題の原因だと判明したら、解決策として、コンフィギュレーションに次のプロパティを追加します。 これにより、Java が乱数を生成する方法が、常に高速なメソッドに変わります。 私たちは、これがセキュリティにどのように影響するかについては何も主張できませんが、セキュリティに関してはご自身で調査して、 より良い解決策があれば是非お知らせください。 尚、既存のコンフィギュレーションと重複しない数字を使用してください。

# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

これは、プラットフォーム固有の解決策です。 プラットフォームに依存しないコンフィギュレーションが必要な場合、新しい wrapper-linux.conf コンフィギュレーションファイルを作成してください。

#encoding=UTF-8
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

次に、メインコンフィギュレーションファイルのプラットフォームに基づいてそちらを含めます。 その場合、番号付きプロパティを誤って再利用しないようにメインコンフィギュレーションにコメントを追加します。

#encoding=UTF-8
#include ../conf/wrapper-%WRAPPER_OS%.conf
...
# Solve slow random initialization on Linux
#wrapper.java.additional.20= # Reserved for use in wrapper-linux.conf