一般的に、アプリケーションは 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-64-3.5.54-pro\bin\wrapper.exe」に署名が見つかりましたが、一致しません: (エラーコード： 0x800b010a）
信頼されたルート証明機関に証明書チェーンを構築できませんでした。 (0x800b010a)
wrapper  |   署名者証明: 
wrapper  |     シリアル番号： 
wrapper  |       00 bf de 76 64 f1 1a d5 f3 dd af a7 e4 d7 c7 0f 5e
wrapper  |     発行者名: Sectigo RSA Code Signing CA
wrapper  |     件名: Tanuki Software Ltd.
wrapper  |   タイムスタンプ証明:
wrapper  |     シリアル番号： 
wrapper  |       39 4c 25 e1 7c a0 6d 27 a8 65 e2 3b d9 1d 22 d4
wrapper  |     発行者名: Sectigo RSA Time Stamping CA
wrapper  |     件名: Sectigo RSA Time Stamping Signer #4
wrapper  |     タイムスタンプ日時 : 2023/05/12 06:24:23
wrapper  | Wrapper 停止します。

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

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

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

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

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

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

下記ページで証明書をダウンロードできます。

https://www.sectigo.com/knowledge-base/detail/Sectigo-Intermediate-Certificates/kA01N000000rfBO

ダウンロードリンクは、「Code Signing - Intermediate」セクションにあります。標準タイプ「Standard」をダウンロードしてください。

Wrapper ver. 3.5.46 以降、「For Code Signing Certificates, issued on or after June 1, 2021」下の標準タイプ「Standard」証明書をダウンロードしてください。

「Sectigo Public Code Signing CA R36」と「SectigoPublicCodeSigningRootR46_AAA [ Cross Signed ]」、両方の証明書は Wrapper に対応します。 ルート証明書、中間証明書、クロスサイン証明書の紹介について、Sectigo 社のウェブサイト（英文）をご覧ください。

https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots

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

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

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」ハッシュのみを検証できます。

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

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

Windows がコードサイニングされたバイナリを起動するときに、先にバイナリが改ざんされていないことを確認するために バイナリをチェックして署名と一致することを確認します。 通常、バイナリを確認する際に使用される Sectigo 証明書は 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