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

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