このトピックでは、 Java 2 Platform Enterprise Edition (J2EE) アプリケーション・クライアントの共通の問題を解決するためのデバッグに関するヒントを記載します。 このトラブルシューティング・ガイドを使用するには、 J2EE アプリケーション・クライアントの例外の 1 つのトレース項目を検討し、次にガイドの中でその例外を見つけます。
ガイドの中のエラーの一部はサンプルです。 実際に受け取るエラーは、ここに示されているものとは異なる場合があります。 また、-CCverbose=true オプションを指定して launchClient コマンドを再実行することも有効です。 このオプションは、J2EE アプリケーション・クライアント・ランタイムが初期化されるときに追加情報を提供します。
説明 | この例外は、指定されたクラスを Java コードがロードできない場合にスローされます。 |
考えられる原因 |
|
推奨される対応 | 指定されたクラスがエンタープライズ・アーカイブ (EAR) ファイル内の Java アーカイブ (JAR) ファイルに存在しているかどうかを確認します。
存在する場合には、そのクラスのパスが正しいことを確認します。
例えば、次のような例外を受け取った場合、java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHomeEAR ファイル内の JAR ファイルの 1 つに HelloHome クラスが存在することを確かめます。 存在する場合には、そのクラスのパスが WebSphereSamples.HelloEJB であることを確かめます。 クラスとパスが両方とも正しい場合には、例外はクラスパスの問題です。
おそらく、クライアントの JAR ファイルのマニフェストの中に指定される、
障害のあるクラスの JAR ファイルがありません。
これを検証するには、以下のステップを実行します。
Classpath フィールドに複数の JAR ファイルを入力する場合には、 JAR 名の間をスペースで分離するようにしてください。 それでも問題が解決しない場合は、 クラスが、EAR ファイルではなく、ファイル・システムからロードされた可能性があります。 問題のクラスが例外に指定されているクラスではないため、 このエラーをデバッグすることは困難です。 あるいは、例外に指定されているクラスより前に、別のクラスがファイル・システムからロードされました。 このエラーを訂正するには、-CCclasspath オプションで指定されたクラスパ ス、およびアプリケーション・クライアント・リソース構成ツールで構成されたクラスパスを調べます。 EAR ファイルにも存在するクラスを探します。 .ear ファイルでなく、ファイル・システム上でクラスの 1 つが検出された状況を解決する必要があります。 クラスパスから項目を除去するか、 あるいは .jar ファイルおよびクラスを、ファイル・システムから参照するのではなく、.ear ファイルに組み込みます。 ツールで -CCclasspath パラメーターまたは リソース・クラスパスを使用し、複数の JAR ファイルまたはクラスを構成し ている場合には、ご使用のオペレーティング・システム用の正しい区切り文字 が使用されていることを確かめてください。 Classpath フィールドとは違って、これらのクラスパス・フィールドはプラ ットフォーム固有の区切り文字を使用します。
ヒント: launchClient バッチ・ファイルまたはシェル・ファイルを使用する場合、
システム・クラスパスは、アプリケーション・クライアント・ランタイムによって使用されません。
この場合には、システム・クラスパスはこの問題を起こしません。
しかし、launchClient クラスを直接ロードする場合には、
システム・クラスパスも探す必要があります。
|
説明 | ホスト・サーバー上にインストールされていないオブジェクトの検索を実行すると、この例外が発生します。 ユーザーのプログラムはローカル・クライアント Java Naming and Directory Interface (JNDI) のネーム・スペースでその名前をルックアップすることができますが、 それはホスト・サーバーにはないので NameNotFoundException 例外を受け取りました。 1 つの代表的な例は、 アクセスするホスト・サーバーにインストールされていない EJB コンポーネントを検索するというものです。 この例外は、アプリケーション・クライアント・モジュールに構成した JNDI 名が、 ホスト・サーバー上のリソースの実際の JNDI 名と一致しない場合にも起こります。 |
考えられる原因 |
|
推奨される対応 | 間違ったホスト・サーバーにアクセスしている場合は、 正しいホスト・サーバー名を指定する -CCBootstrapHost パラメーターを用いて、 launchClient コマンドを再度実行します。 正しいホスト・サーバーにアクセスしている場合には、 製品の dumpnamespace コマンド行ツールを使用して、 ホスト・サーバーの JNDI ネーム・スペースのリストを参照します。 障害を起こしたオブジェクトの名前が見つからない場合には、 リソースがホスト・サーバーにインストールされていないか、 あるいは適切なアプリケーション・サーバーが開始されていないかのどちらかです。 リソースがすでにインストールされており開始されていることが判明した場合には、 クライアント・アプリケーション内の JNDI 名がホスト・サーバー上のグローバル JNDI 名と一致しません。 Application Server Toolkit を使用して、 クライアント・アプリケーション内の障害を起こしたオブジェクト名の JNDI バインディング値を ホスト・サーバー・アプリケーション内のオブジェクトの JNDI バインディング値と比較します。 これらの値は一致しなければなりません。 |
説明 | この例外は、無効なホスト・サーバー名を指定すると発生します。 |
考えられる原因 |
|
推奨される対応 | launchClient コマンドを再度実行し、-CCBootstrapHost パラメーターを用いて、 ホスト・サーバーの正しい名前を指定します。 |
説明 | この例外は、 始動済みアプリケーション・サーバーを持たないホスト・サーバーに対して launchClient コマンドを実行すると発生します。 この例外は、無効なホスト・サーバー名を指定した場合にも起こります。 これは、launchClient ツールを実行するときにホスト・サーバー名を指定しないと起こることがあります。 WebSphere Application Server はユーザーのホスト・サーバーの名前を知らないので、 デフォルトの振る舞いでは、launchClient ツールがローカル・ホストを対象として実行することになります。 このデフォルトの振る舞いは、 WebSphere Application Server がインストールされているマシン上でクライアントを実行させている場合にのみ動作します。 |
考えられる原因 |
|
推奨される対応 | 正しいホスト・サーバーに対して実行していない場合は、launchClient コマンドを再度実行し、 -CCBootstrapHost パラメーターを使ってホスト・サーバーの名前を指定します。 そうでなければ、ホスト・サーバー上の Application Server を開始して、 launchClient コマンドを再実行します。 |
説明 | この例外は、LDAP (Windows 2000 Active Directory) ユーザー ・レジストリーを使用して、管理、アプリケーション、および Java 2 セキ ュリティーを使用可能にすると発生します。 デプロイ メント・マネージャーは、正常に再始動されますが、ユーザーは管理コンソー ルにログインすることはできません。 エラー・メッセージは、SystemOut.log に表示され ます。 |
考えられる原因 |
|
推奨される対応 | 「SSL 使用可能 」オプションのチェック・マークを 外し、接続を再試行します。 「SSL 使用可能 」オプションは、WebSphere Application Server プラグインとアプリケーション・サーバー間の接続を SSL を使用して保護するか どうかを指定します。 デフォルトでは SSL を使用しません。 |
説明 | この例外は、指定された名前を Java コードがローカル JNDI ネーム・スペース内で見つけられない場合にスローされます。 |
考えられる原因 |
|
推奨される対応 | Application Server Toolkit を用いて EAR ファイルを開き、 障害の原因となっている名前に対するバインディングを検査します。 この情報が正しいことを確かめます。 リソース参照を使用している場合には、 アプリケーション・クライアント・リソース構成ツールを用いて EAR ファイルをオープンし、 リソース参照にクライアント構成情報があること、 およびリソース参照の名前とクライアント構成の JNDI 名が完全に一致することを確認してください。 この値が正しい場合には、クラス・ローダー・エラーがあることが考えられます。 |
説明 | この例外は、 アプリケーション・プログラムが EJB のホーム・クラスに対して絞り込みを試み、 クラス・ローダーが EJB のクライアント・サイド・バインディングを検出できない場合に発生します。 |
考えられる原因 |
|
推奨される対応 | .ear ファイル内に配置されている EJB .jar ファイルを調べて、 クラスが Enterprise Java Beans (EJB) クライアント・サイド・バインディングを含んでいるかどうか検査します。 これらのファイルは、 名前が _Stub および _Tie で終わるクラス・ファイルです。 バインディング・クラスが EJB .jar ファイルにある場合には、 クラス・ローダー・エラーが生じることがあります。 |
説明 | このエラーは、 アプリケーション・クライアント・ランタイムがエンタープライズ・アーカイブ (EAR) ファイルを読み取れないときに起こります。 |
考えられる原因 | このエラーの原因として最も可能性が高いのは、 launchClient コマンドで指定されたパスに EAR ファイルが見つからないことです。 |
推奨される対応 | launchclient コマンドで指定したパスとファイル名が正しいことを確認してください。
|
説明 | launchClient コマンドを使用してアプリケーション・クライアントを実行していると、 WebSphere Application Server ランタイムが、セキュリティー・ログイン・ダイアログの表示を必要とする場合があります。 このダイアログを表示するために、 WebSphere Application Server ランタイムは Abstract Window Toolkit (AWT) スレッドを作成します。 アプリケーションが、その main メソッドからアプリケーション・クライアント・ランタイムに戻されるときに、 アプリケーション・クライアント・ランタイムは、オペレーティング・システムへのリターンを試み、 Java 仮想マシンを終了します。 しかし、AWT スレッドがあるので、 JVM コードは、System.exit が呼び出されるまでは終了しません。 |
考えられる原因 | AWT スレッドがあるために、JVM コードが終了しません。 Java コードには、AWT スレッドを終了するために呼び出される System.exit() が必要です。 |
推奨される対応 |
|
説明 | アプレット・クライアント・アプリケーションは、Windows システムでのみ実行されます。
アプレット・クライアント・アプリケーションが実行されると、
ブラウザーのウィンドウにアプリケーション出力データが表示されます。
Internet Explorer と Windows XP オペレーティング・システム Service Pack 2 を使用している場合は、 出力データを表示しようとしてエラーになることがあります。 |
考えられる原因 | |
推奨される対応 | Windows XP オペレーティング・システム Service Pack 2 の場合は、次のアクションを実行します。
|
説明 | WebSphere Application Server トレーダー・アプレット・クライアントは、Red Hat Enterprise Linux®、Red Flag Linux Adv Server および SuSE Linux プラットフォーム上の Sun Java™ Virtual Machine (JVM™) プラグイン・バージョン 1.4.1_02 では正常に機能しません。 |
考えられる原因 | WebSphere Application Server トレーダー・アプレット・クライアントは、Red Hat Enterprise Linux、Red Flag Linux Adv Server および SuSE Linux プラットフォーム上の Sun JVM plug-in version 1.4.1_02 には対応していません。 |
推奨される対応 | 前述のプラットフォームのいずれかで WebSphere Application Server を稼働する場合は、Windows 2003 などのサポートされている別のプラットフォームのブラウザーを使用してサンプルを実行します。 |
説明 | 管理対象外クライアントを呼び出すときに、"NoClassDefFoundError: Invalid Implementation Key" 例外が WebSphere Application
Server のクラスで表示されることがあります。以下の例を参照してください。Exception in thread "main" java.lang.NoClassDefFoundError: Invalid Implementation Key, com.ibm.ws.util.PlatformHelper at com.ibm.ws.util.ImplFactory.loadClassFromKey(ImplFactory.java:230) at com.ibm.ws.util.ImplFactory.loadImplFromKey(ImplFactory.java:179) at com.ibm.ws.util.ImplFactory.loadImplFromKey(ImplFactory.java:185) at com.ibm.ws.util.PlatformHelperFactory.getPlatformHelper(PlatformHelperFactory.java:51) ... |
考えられる原因 | この問題は、WebSphere Application Server JAR ファイルのマニフェストからクラス・パス・エントリーが除去されている ことが原因であると推測されます。前のバージョンと比較すると変更されているこの動作は、意図的なものです。 WebSphere Application Server の実装の詳細に、依存関係を作成することはお勧めできません。 |
推奨される対応 | 推奨されるソリューションは、Java システム・プロパティーを使用して WebSphere ライブラリー・ディレクトリーを JDK 拡張クラス・ローダー・ク ラスパスに追加することです。これは、次のように行います。「-Djava.ext.dirs=$JAVA_HOME/jre/lib/ext;$WAS_EXT_DIRS」ここで 、$WAS_EXT_DIRS は setupCmdLine.bat または setupCmdLine.sh に定義されているか、少なくとも $WAS_HOME/lib を含む必要があります。 詳しくは、次のトピック、サーバー・マシンでのシン・アプリケーション・クライアント・コードの開発を参照してください。 WebSphere Application Server ライブラリー
JAR ファイルをロードするために独自のカスタマイズ済みクラス・ローダー
が必要な場合は、より優先度の低いアプローチが使用できます。
この優先度の低いメソッドには、カスタム・クラス・ローダーを作成した後
で直ちにカスタマイズ済みクラス・ローダーに設定するスレッド・コンテキス
ト・クラス・ローダーが必要です。
Thread.currentThread().setContextClassLoader(...);このアプ ローチはさらにお勧めできません。クラスの依存関係および階層の代行モー ドに起因する潜在的な危険により、管理対象外クライアント環境での独自のカ スタマイズ済みクラス・ローダーの使用について注意する必要があるからです 。 この潜在的な障害の結果である共通問題の例は、classNotFoundException です。 |
説明 | Application Client バージョン 6.0.0 インストーラーで Developer Kit フィーチャーを選択した場合は、すべてのファイルが Java Runtime Environment (JRE) ファイルをそのままにしておく代わりに、<client_install_root>/java ディレクトリー下にインストールされます。 JRE ファイルは予期せずバージョン 6.0.0 レベルにダウングレードされます。 |
考えられる原因 | Application Client 6.0.0 インストーラーで Developer Kit フィーチャーを選択すると、JRE ファイルがそのまま残るのではなく、実際に <client_install_root>/java ディレクトリーの下にすべてのファイルがインストールされます。 したがって、上記のインストール・シナリオでは JRE ファイルが予期せず 6.0.0 レベルにダウングレードされます。 |
推奨される対応 | 次のインストール・ステップを実行して、予期しない JRE ファイルのダウングレードを防ぎます。 |