クラス・ローダーは、クラス・ファイルを検出し、ロードします。デプロイされたアプリケーションを正常に稼働させるには、アプリケーションおよびそのモジュールに影響するクラス・ローダーは、アプリケーションが必要とするファイルおよびリソースを検索できるよう構成される必要があります。クラス・ローダーでの問題の診断は、複雑で面倒な場合があります。
問題の診断と修正をより迅速に行うには、管理コンソールのクラス・ローダー・ビューアーを使用して、
クラス・ローダーおよび各クラス・ローダーによりロードされるクラスを調べます。
始める前に
このトピックでは、アプリケーションを
WebSphere Application Server でサポートされるサーバーにインストールしていること、
およびアプリケーションまたはそのモジュールが使用するクラス・ローダーを調べることを前提とします。モジュールは、Web モジュール
(
.war ファイル) であることも、エンタープライズ Bean (EJB) モジュール (
.jar ファイル) であることもあります。 クラス・ローダー・ビューアーは、ランタイム環境におけるクラス・ローダーを調べることができます。
また、このトピックは、クラス・ローダー・ビューアーのサービスが使用可能になっていることも前提としています。
をクリックしてサービスを使用可能にし、
サーバーを再始動します。
このタスクについて
WebSphere Application Server
のランタイム環境は、以下のクラス・ローダーを使用して、以下の順にアプリケーションの新規のクラスを検索して、それをロードします。
- Java 仮想マシンで作成される、ブートストラップ、拡張、および CLASSPATH のクラス・ローダー。
- WebSphere 拡張クラス・ローダー。
- サーバーで稼働中のエンタープライズ・アプリケーションのエレメントをロードする、1 つ以上のアプリケーション・モジュール・クラス・ローダー
- ゼロ以上の Web モジュール・クラス・ローダー

各クラス・ローダーは、直前のクラス・ローダーの子になっています。
つまり、アプリケーション・モジュール・クラス・ローダーは WebSphere 拡張クラス・ローダーの子です。
さらに、WebSphere 拡張クラス・ローダーは CLASSPATH Java クラス・ローダーの子です。通常は、クラスをロードする
必要があるたびに、クラス・ローダーは要求を親クラス・ローダーに委任します。
どの親クラス・ローダーもクラスを検索できない場合は、元のクラス・ローダーがクラ
スをロードしようとします。
要求は親クラス・ローダーに送ることしかできず、子クラス・ローダーに送ることはで
きません。
クラスがクラス・ローダーによってロードされると、ロードしようとする新規のクラスは、同じクラス・ローダーを再利用するか、クラスが検出されるまで優先順位リストを上にたどります。
アプリケーションの成果物をロードするクラス・ローダーが正しく構成されていない場合、
アプリケーションを開始または実行する際に JVM がクラス・ロード例外をスローすることがあります。クラス・ロード例外
では、正常に構成されなかったクラス・ローダーにより発生する例外のタイプ、およびクラス・ローダーを正しく構成するクラス・ローダー・ビューアーの使用方法が説明されています。例外のタイプには、以下のものがあります。
クラス・ローダー・ビューアーを使用して、クラス・ローダーを調べ、アプリケーションまたはクラス・ローダー構成の問題を修正する一般的な方法を以下の手順に示します。
プロシージャー
- インストールされているすべてのアプリケーション
とそのモジュールをリストしているツリー表示を調べます。モジュールは、Web モジュール (.war ファイル) または EJB モジュール (.jar ファイル) である場合があります。
をクリックして、エンタープライズ・アプリケーション・トポロジー・ページにアクセスします。
- クラス・ローダーの委任階層を調べます。
「エンタープライズ・アプリケーション・トポロジー・ページ」で、モジュールを選択し、クラス・ローダー・ビューアー・ページへアクセスします。
このページでは、インストールしたエンタープライズ・アプリケーションの Web および EJB モジュールに対して可視のクラス・ローダーをリストします。このページは、どのクラス・ローダーがモジュールのファイルをロードしたのかを判別したり、
クラス・ローダーでの問題を診断したりする場合に有用です。
委任階層は、アプリケーションまたは Web
モジュールに指定される、クラス・ローダー委任モード、またはクラス・ローダー・オーダー により決まります。
モジュール値は、「最初に親クラス・ローダーをロードしたクラス」または 「最初にアプリケー
ション・クラス・ローダーをロードしたクラス」です。
詳しくは、クラス・ローダーの構成の手順を参照してください。
- クラス・ローダーの情報をエクスポートします。
- クラス・ローダー・ビューアー・ページで、「Export」をクリックします。
- クラス・ローダー情報で、ブラウザーまたはエディターを開くことを選択するか、XML 形式で情報をディスクに保管します。
- 「OK」をクリックし、システムから要求される追加情報を指定します。
- HTML テーブル形式で、モジュールに対し可視のクラス・ローダーに関する情報を表示します。
クラス・ローダー・ビューアー・ページで、「テーブル・ビュー」をクリックします。
テーブル・ビュー のページでは、以下の情報を表示します。
クラス・ローダー属性 |
説明 |
委任 |
クラス・ローダーがその親クラス・ローダーに対しモジュールのロードを委任するかどうかを示します。
値が true の場合、親アプリケーションのクラス・ローダーが使用されていることを示します (最初に親または最初に親クラス・ローダーをロードしたクラス)。
値が false の場合、モジュールのクラス・ローダーが使用されていることを示します (最後に親または最初に親クラス・ローダーをロードしたクラス)。
詳しくは、クラス・ローダーの構成の手順を参照してください。 |
クラスパス |
クラス・ローダーがクラスやリソースを探すパスをリストします。 |
クラス |
このクラス・ローダーにより、JVM にロードされるクラスの名前をリストします。 |
「テーブル・ビュー」オプションは、メモリー不足エラーが生成された場合は値を戻しません。
メモリー不足エラーはメモリー・リークに関係している可能性があります。テーブル内のクラス・ローダーについての情報を調べるには、
まずメモリー不足エラーを解決した後で、「テーブル・ビュー」を再度クリックします。
- クラス・ローダーを検索します。
クラス・ローダー・ビューアー・ページで、「
検索」をクリックし、
検索ページにアクセスすると、以下のクラス・ローダーを検索することができます。
- 特定のストリング
- 特定の .jar ファイル
- 特定のディレクトリー内のファイルの名前
- 特定のクラス・ローダーによってロード済みのファイルの名前
検索では、大/小文字を区別します。
クラス・ロード例外
では、検索ページの使用についていくつかの使用例を説明します。
- クラス・ローダーを構成します。 以下について、クラス・ローダーを構成することができます。
クラス・ローダー構成は、アプリケーションまたは Web モジュールのクラス・ファイルおよびリソース・ファイルをロードするクラス・ローダーを判別します。
「Application and WAR module class configuration settings」には、
「クラス・ローダーの順序」および「WAR class loader policy」が含まれます。
クラス・ローダーの順序 値は、
親クラス・ローダーでロードされるクラスが最初 または アプリケーション・クラス・ローダーでロードされるクラスが最初 のどちらかにすることができます。
デフォルトは 親クラス・ローダーでロードされるクラスが最初 です。
親クラス・ローダーでロードされるクラスが最初 モードのクラス・ローダーは、クラスパスを検索する前に、
直接の親クラスへのクラスまたはリソースのロードを代行します。
クラス・ロードの問題のトラブルシューティングを行う際に、親クラス・ローダーに対して可視のクラスをオーバーライドする
必要がある場合があります。アプリケーションに固有のクラスを使用してそれらのクラスをオーバーライドするには、
そのアプリケーション・クラスをクラスパス上に含むクラス・ローダーで、
クラス・ローダーの順序 を
アプリケーション・クラス・ローダーでロードされるクラスが最初 にセットします。
アプリケーションは、親クラス・ローダーに対して可視のクラスをオーバーライドすることができますが、これを行うことによって、
オーバーライドされたクラスとオーバーライドされないクラスの使用が混在する場合に、ClassCastException または UnsatisfiedLinkError が
発生することがあります。
例えば、デフォルトのクラス・ローダー・ポリシーの下では、
Web モジュールは独自の Web モジュール (WAR) クラス・ローダーを持ち、通常 WEB-INF/classes ディレクトリー
および WEB-INF/lib ディレクトリーにある成果物をロードします。
アプリケーション・モジュール・クラス・ローダーは、WAR クラス・ローダーの直接の親です。
Web モジュール・クラス・ローダーが、アプリケーション・モジュール・クラス・ローダーへのロード操作を代行する前に
これらのパスで特定のクラスやリソースを検索することを確認するには、
Web モジュールのクラス・ローダーの順序 を
アプリケーション・クラス・ローダーでロードされるクラスが最初 に設定してください。
クラス・ローダー・ポリシーにより、アプリケーション・モジュール・クラス・ローダーおよび WAR モジュール・クラス・ローダーの構造が
決定します。デフォルト・ポリシーでは、稼働中のすべてのアプリケーション EAR は
独自のアプリケーション・モジュール・クラス・ローダーを持ち、またすべての Web モジュールは独自の WAR モジュール・クラス・ローダーを
持ちます。デフォルト・ポリシーは、アプリケーションの成果物の間の可視性や独立性に関する J2EE 準拠を保証します。
クラス・ロードの問題のトラブルシューティングの際にデフォルト・ポリシーを変更することは推奨されていません。