クラス・ローダー

クラス・ローダーは、クラス・ファイルを検出し、ロードします。クラス・ローダーにより、 サーバー上にデプロイされたアプリケーションは使用可能なクラスおよびリソースのリポジトリーにアクセスすることができます。 アプリケーションの開発者およびデプロイヤーは、クラスおよびリソースのファイルのロケーション、およびそれらのファイルのアクセスに使用されるクラス・ローダーを考慮し、デプロイ済みのアプリケーションでそのファイルを使用可能にする必要があります。

WebSphere® Application Server におけるクラス・ローダーに関する以下の情報を参照します。

使用されるクラス・ローダーおよび使用順序

製品のランタイム環境は、以下のクラス・ローダーを使用して、以下の順にアプリケーションの新規のクラスを検索して、それをロードします。

  1. Java™ 仮想マシンで作成される、ブートストラップ、拡張、および CLASSPATH のクラス・ローダー。

    ブートストラップ・クラス・ローダーは、ブート・クラスパス (通常は jre/lib の クラス) を使用して、クラスを検索およびロードします。 拡張クラス・ローダーは、システム・プロパティー java.ext.dirs (通常は jre/lib/ext) を使用して、クラスを検索およびロードします。CLASSPATH クラス・ローダーは、CLASSPATH 環境変数を使用して、クラスを検索および ロードします。

  2. WebSphere 拡張クラス・ローダー。

    WebSphere 拡張クラス・ローダーは、実行時に必要な WebSphere Application Server クラスをロードします。 WebSphere Application Server クラスは、OSGi バンドルのセットとして提供されます。各バンドルは、 OSGi クラス・ローダーのネットワーク内で、個別のクラス・ローダーによってロードされます。拡張クラス・ローダーはゲートウェイ・クラス・ローダーに委任して、 この OSGi クラス・ローダー・ネットワークからクラスをロードします。OSGi クラス・ローダー・ネットワークからエクスポートされたパッケージは、 ゲートウェイを通してアプリケーションに対して可視です。詳しくは、OSGi クラス・ローダー・モデルを参照してください。

    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): Java Platform, Enterprise Edition (Java EE) アプリケーション・プログラミング・インターフェース (API) は、javax.j2ee.*.jar バンドルで提供されます。これは、OSGi クラス・ローダー・ネットワーク内にロードされ、ゲートウェイを通してアプリケーションに対して可視になります。OSGi バンドル内にデプロイされたクラスは、 Java 仮想マシン・クラス・ローダーに対しては可視ではないため、Java EE API に依存するライブラリーへのパスを指定する際は、CLASSPATH 環境変数を使用しないでください。java.ext.dirs システム・プロパティーおよび java.lang.classpath システム・プロパティーも使用しないでください。また、CLASSPATH、java.ext.dirs、および java.lang.classpath を使用してアプリケーション・ライブラリーへのパスを指定することもしないでください。これらのライブラリーがリンケージ・エラーまたは予期しないサーバー動作を引き起こす可能性があるためです。gotcha

    WebSphere 拡張クラス・ローダーは、OSGi バンドル内で提供されているクラスやリソース以外のクラスやリソースをロードするために使用するパスの判別に、ws.ext.dirs システム・プロパティーを使用します。ws.ext.dirs クラスパスの各ディレクトリー、およびこれらのディレクトリー内のすべての Java アーカイブ (JAR) ファイルまたは圧縮ファイルは、このクラス・ローダーが使用するクラスパスに追加されます。

    WebSphere 拡張機能のクラス・ローダーは、サーバーにインストールされているア プリケーション・モジュールがリソース・プロバイダーに関連付けられたリソースを参照 する場合、およびそのプロバイダーがリソース・ドライバーのディレクトリー名を指定する場合は、リソース・プロバイダーのクラスをサーバーにロードします。

  3. サーバーで稼働中のエンタープライズ・アプリケーションのエレメントをロードする、1 つ以上のアプリケーション・モジュール・クラス・ローダー

    アプリケーションのエレメントとは、 Web モジュール、エンタープライズ Bean (EJB) モジュール、 リソース・アダプター・アーカイブ (RAR ファイル)、および依存関係 JAR ファイルです。 アプリケーション・クラス・ローダーは、Java EE クラス・ロード規則に従って、 クラスや JAR ファイルをエンタープライズ・アプリケーションからロードします。 この製品を使用すると、共有ライブラリーをアプリケーションに関連付けることができます。

  4. ゼロ以上の Web モジュール・クラス・ローダー

    デフォルトで、Web モジュール・クラス・ローダーは、WEB-INF/classes および WEB-INF/lib の各ディレクトリーの内容をロードします。Web モジュール・クラス・ローダーは、 アプリケーション・クラス・ローダーの子です。アプリケーション・クラス・ローダーが、 Web モジュール・クラス・ローダーではなく Web モジュールの内容をロードするように、 指定することができます。

クラス・ローダーの階層

各クラス・ローダーは、直前のクラス・ローダーの子になっています。 つまり、アプリケーション・モジュール・クラス・ローダーは WebSphere 拡張クラス・ローダーの子です。 さらに、WebSphere 拡張クラス・ローダーは CLASSPATH Java クラス・ローダーの子です。通常は、クラスをロードする 必要があるたびに、クラス・ローダーは要求を親クラス・ローダーに委任します。 どの親クラス・ローダーもクラスを検索できない場合は、元のクラス・ローダーがクラ スをロードしようとします。 要求は親クラス・ローダーに送ることしかできず、子クラス・ローダーに送ることはで きません。 WebSphere 拡張クラス・ローダーが Java EE モジュールでクラスを検索するように要求された場合、 アプリケーション・モジュール・クラス・ローダーで当該クラスを検索することはできず、ClassNotFoundException エラーが発生します。クラスがクラス・ローダーによってロードされると、ロードしようとする新規のクラスは、同じクラス・ローダーを再利用するか、クラスが検出されるまで優先順位リストを上にたどります。

クラス・ローダー分離ポリシー

アプリケーション・モジュール・クラス・ローダーの数および機能は、サーバー構 成で指定されたクラス・ローダー・ポリシーによって異なります。 クラス・ローダーは、アプリケーションとモジュールを分離して、異なるアプリケーシ ョン・パッケージ化スキームをアプリケーション・サーバーで実行できるようにするため のオプションを複数用意しています。

2 つのクラス・ローダー・ポリシーは、アプリケーションとモジュールの分離を制御します。

表 1. クラス・ローダー・ポリシーの説明. 使用可能なポリシーにはアプリケーションや WAR があります。
クラス・ローダー・ポリシー 説明
アプリケーション アプリケーション・クラス・ローダーは、EJB モジュール、依存関係 JAR ファイル、 組み込みリソース・アダプター、およびアプリケーション・スコープの共有ライブラリーをロードします。アプリケーション・クラス・ローダー・ポリシーによって、アプリケーション・クラス ・ローダーを複数のアプリケーションで共有することも (Single)、アプリケーションご とに固有とすることもできます (Multiple)。 アプリケーション・クラス・ローダー・ポリシーは、 システムで稼働中のアプリケーションの分離を制御します。 Single に設定すると、アプリケーションは分離されません。 Multiple に設定すると、アプリケーションは互いに分離されます。
WAR デフォルトで、Web モジュール・クラス・ローダーは、WEB-INF/classes および WEB-INF/lib の各ディレクトリーの内容をロードします。 アプリケーション・クラス・ローダーは、Web モジュール・クラス・ローダーの親です。 アプリケーションの Web アプリケーション・アーカイブ (WAR) クラス・ローダー・ポリシーを変更することで、デフォルトの振る舞いを変更できます。

WAR クラス・ローダー・ポリシーは、Web モジュールの分離を制御します。このポリシーを Application に設定する と、(EJB ファイル、RAR ファイル、依存関係 JAR ファイル、および共有ライブラリー に加えて) Web モジュールの内容も、アプリケーション・クラス・ローダーによってロードされます。 ポリシーを Module に設定すると、各 Web モジュールは、アプリケーション・クラス・ローダーを親に持つ独自のクラス・ローダーを受け取ります。

ヒント: コンソールおよび基礎となる deployment.xml ファイルでは、WAR クラス・ローダー・ポリシーの値にそれぞれ異なる名前が使用されます。コンソールでは、WAR クラス・ローダー・ポリシーの値は Application または Module です。しかし、ポリシーが設定されている、基礎となる deployment.xml ファイルでは、WAR クラス・ローダー・ポリシーの値は、Application ではなく Single であるか、または Module ではなく Multiple です。ApplicationSingle と同一で、ModuleMultiple と同一です。
制約事項: WebSphere Application Server クラス・ローダーが、アプリケーション・クライアント・モジュールをロードすることはありません。

アプリケーション・クラス・ローダー・ポリシーは、システム内のアプリケーション ・サーバーごとに、Single または Multiple に設定できます。 アプリケーション・クラス・ローダー・ポリシーを Single に設定すると、単一のアプリケーション・クラス・ローダーは、システム内のすべての EJB モジュール、依存関係 JAR ファイル、および共有ライブラリーをロードします。 アプリケーション・クラス・ローダー・ポリシーを Multiple に設定すると、各アプリケーションは、そのアプリケーションの EJB モジュール、依存関係 JAR ファイル、および共有ライブラリーのロードに使用される独自のクラス・ローダーを受け取ります。

アプリケーション・クラス・ローダーは、 アプリケーションの WAR クラス・ローダー・ポリシーが Application に設定されている場合は、Web モジュールからクラスをロードします。 アプリケーションの WAR クラス・ローダー・ポリシーを Module に設定すると、 各 WAR モジュールは独自のクラス・ローダーを受け取ります。

以下の例は、アプリケーション・クラス・ローダー・ポリシーを Single に設定すると、単一のアプリケーション・クラス・ローダーは、サーバー上のすべてのアプリケーションのすべての EJB モジュール、依存関係 JAR ファイル、および共有ライブラリーをロードすることを示しています。 単一のアプリケーション・クラス・ローダーは、アプリケーションの WAR クラス・ロー ダー・ポリシーが Application に設定されている場合には、Web モジュールもロードす ることができます。 WAR クラス・ローダー・ポリシーが Module に設定されているアプリケーションは、Web モジュール用に別のクラス・ローダーを使用します。

Server's application class-loader policy: Single
Application's WAR class-loader policy: Module

Application 1
		Module: 	EJB1.jar
		Module:	WAR1.war
	 		 	MANIFEST Class-Path: Dependency1.jar
				WAR Classloader Policy = Module
Application 2
		Module:  	EJB2.jar
				MANIFEST Class-Path: Dependency2.jar
		Module:	WAR2.war
				WAR Classloader Policy = Application
SINGLE クラス・ローダー・ポリシー

以下の例は、アプリケーション・サーバーのアプリケーション・クラス・ローダー・ ポリシーが Multiple に設定されている場合は、サーバー上の各アプリケーションに独自のクラス・ローダーがあることを示しています。 アプリケーション・クラス・ローダーは、アプリケーションの WAR クラス・ローダー・ポリシーが Application に設定されている場合、その Web モジュールもロードします。 ポリシーが Module に設定されている場合は、Web モジュールは独自のクラス・ローダーを使用します。

Server's application class-loader policy: Multiple
Application's WAR class-loader policy: Module

Application 1
		Module: 	EJB1.jar
		Module:	WAR1.war
			 	MANIFEST Class-Path: Dependency1.jar
				WAR Classloader Policy = Module
Application 2
		Module:  	EJB2.jar
				MANIFEST Class-Path: Dependency2.jar
		Module:	WAR2.war
				WAR Classloader Policy = Application
MULTIPLE クラス・ローダー・ポリシー

クラス・ローダー・モード

クラス・ローダー・オーダー とも呼ばれるクラス・ローダー代行モードは、クラス・ローダーがクラスのロードをその親のクラス・ローダーに代行させるかどうかを決定します。クラス・ローダー・モードに対しては、以下の値がサポートされています。

表 2. クラス・ローダー・モードの説明. 使用可能なモードには「親が最初」や「親が最後」があります。
クラス・ローダー・モード 説明
親が最初

最初に親の クラス・ローダーを使用してロードされたクラスとも呼ばれます。

クラス・ローダー・モードの 「親が最初」では、 クラス・ローダーは、 ローカル・クラスパスからのクラスのロードを試行する前に、 親クラス・ローダーにクラスのロードを委任します。 この値は、クラス・ローダー・ポリシーおよび標準 JVM クラス・ローダーではデフォルトです。
親が最後

最初にローカル・クラス・ローダーでロードしたクラス」または「アプリケーションが最初 (Application first)」とも呼ばれます。

クラス・ローダー・モードの 「親が最後」では、 クラス・ローダーは、 クラスのロードをその親に委任する前に、 ローカル・クラスパスからクラスをロードしようとします。 このポリシーを使用すると、アプリケーション・クラス・ローダーは、 親クラス・ローダーに存在する独自のバージョンのクラスをオーバーライドして提供できます。

以下の設定で、クラス・ローダーのモードが決定されます。

  • アプリケーション・サーバーのアプリケーション・クラス・ローダー・ポリシーが Single の場合は、 サーバー・レベル・モードの値がアプリケーション・クラス・ローダーのモードを定義します。
  • アプリケーション・サーバーのアプリケーション・クラス・ローダー・ポリシーが Multiple の場合は、 アプリケーション・レベル・モードの値がアプリケーション・クラス・ローダーのモードを定義します。
  • アプリケーションの WAR クラス・ローダー・ポリシーが Module の場合は、モジュール・レベル・モードの値が WAR クラス・ローダーのモードを定義します。

OSGi クラス・ローダー・モデル

OSGi は、マニフェスト・ファイル内のメタデータをクラス・ローダー・モードとして使用します。OSGi にグローバル・クラスパスはありません。バンドルが OSGi フレームワークにインストールされる場合、そのメタデータはモジュール・レイヤーによって処理され、その宣言済み外部依存関係は、他のインストール済みモジュールによって宣言されたバージョン管理エクスポートに対して照合されます。 OSGi フレームワークは、すべての依存関係を解決し、各バンドルの独立必須クラスパスを計算します。この方法では、以下の要件が満たされるようにすることで、プレーン Java クラス・ロードの欠点が解決されます。
  • 各バンドルが、明示的にエクスポートする Java パッケージだけに可視性を提供する。
  • 各バンドルが、明示的にそのパッケージの依存関係を宣言する。
  • パッケージは、特定バージョンでエクスポートでき、特定のバージョンで、または特定のバージョン範囲からインポートできる。
  • パッケージの複数のバージョンが、異なるクライアントに対して同時に使用可能である。

OSGi について詳しくは、トピック『OSGi フレームワーク』を参照してください。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_classload
ファイル名:crun_classload.html