アプリケーションによるクラス・ローダーの使用の構成

アプリケーションと Web モジュールが、 クラスのロードまたは別のクラス・ローダーの使用のために固有のクラス・ローダーを使用するかどうかを構成することができます。 また、アプリケーション・ファイルを更新する際のクラスの再ロードを構成することもできます。クラス・ローダーにより、アプリケーションは使用可能なクラスおよびリソースのリポジトリーにアクセスすることができます。

始める前に

このトピックでは、アプリケーションまたはモジュールが既にサーバー上にデプロイされていることを前提としています。

以下の注記は、このトピック内の .xmi ファイル参照に適用されます。
サポートされる構成 サポートされる構成: IBM® 拡張ファイル およびバインディング・ファイルの場合、.xmi または .xml ファイル名拡張子は、Java EE 5 より前のアプリケーションまたはモジュールを使用しているか、 あるいは Java™ EE 5 以降のアプリケーションまたは モジュールを使用しているかによって異なります。IBM 拡張 ファイルまたはバインディング・ファイルは、ibm-*-ext.xmi または ibm-*-bnd.xmi という名前です。 ここで * は拡張ファイルまたはバインディング・ファイルのタイプ (app、application、ejb-jar、 または web など) です。以下の条件が適用されます。
  • バージョン 5 より前の Java EE バージョンを使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xmi でなければなりません。
  • Java EE 5 以降を使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xml でなければなりません。.xmi ファイルがアプリケーションまたはモジュールに組み込まれている場合、.xmi ファイルは無視されます。

ただし、Java EE 5 以降のモジュールが、Java EE 5 より前のファイルを含み .xmi ファイル名拡張子を使用する アプリケーション内に存在することは可能です。

ibm-webservices-ext.xmiibm-webservices-bnd.xmiibm-webservicesclient-bnd.xmiibm-webservicesclient-ext.xmi、 および ibm-portlet-ext.xmi ファイルは、引き続き .xmi ファイル拡張子 を使用します。

sptcfg

このタスクについて

クラス・ローダーは、アプリケーションとそのモジュールが、効率的な実行のために必要なリソースを 見つけるかどうかに影響します。アプリケーションと Web モジュールがクラスをロードするために固有のクラス・ローダーを使用するか、 または親クラス・ローダーを使用するかどうかを選択することができます。

アプリケーション・クラス・ローダーは、アプリケーションに関連付けられたエンタープライズ JavaBeans (EJB) モジュール、共有ライブラリー、リソース・アダプター・アーカイブ (RAR ファイル)、および依存関係 Java アーカイブ (JAR) ファイルをグループ化します。 依存関係 JAR ファイルは、エンタープライズ Bean とサーブレットの両方が使用できるコードを含む JAR ファイルです。

アプリケーション・クラス・ローダーは、 Web アプリケーション・アーカイブ (WAR) クラス・ローダーの親です。 デフォルトでは、Web モジュールは Web モジュールの内容をロードするために、独自の WAR クラス・ローダーを持ちます。 アプリケーション・クラス・ローダーの WAR クラス・ローダー・ポリシーの値は、 Web モジュールの内容をロードするために、WAR クラス・ローダーを使用するのか、またはアプリケーション・クラス・ローダーを 使用するのかを決定します。

アプリケーション・ファイルを更新する際に、 クラスを再ロードするかどうかを選択することができます。EJB モジュールまたはすべての非 Web モジュールでは、クラスの再ロードを使用可能にすると、アプリケーション・サーバー・ランタイムによりアプリケーションが停止および開始され、アプリケーション・クラスが再ロードされます。サーブレットや JavaServer Pages (JSP) ファイルなどの Web モジュールの場合、Web コンテナー は、ibm-web-ext.xmi ファイルの IBM 拡張 reloadingEnabled が true に設定されているときにだけ、 Web モジュールの再ロードを行います。

アプリケーションと Web モジュールによるクラス・ローダーの使用を構成するには、 管理コンソールのクラス・ロードと更新の検出ページを使用します。

重要: アプリケーションの実行中に アプリケーション設定を変更すると、アプリケーションは再始動されます。 スタンドアロン・サーバーでは、 変更内容を保存してからアプリケーションが再始動されます。複数サーバー製品では、 変更内容を保存してからアプリケーションが再始動され、 アプリケーションがインストールされているノード上のファイルが同期されます。マルチサーバー製品で同期が発生する時期を制御するには、「コンソール設定」ページの「変更をノードと同期する」を選択解除します。

手順

  1. 「アプリケーション」 > 「アプリケーション・タイプ」 > 「WebSphere エンタープライズ・アプリケーション」 > application_name > 「クラス・ロードおよび更新の検出」をクリックして、「クラス・ロードおよび更新の検出」ページにアクセスします。
  2. アプリケーションまたはアプリケーションのファイルを更新するとき、アプリケーション・クラスを再ロードするかを指定します。

    デフォルトで、クラスの再ロードは使用可能になっていません。アプリケーション・クラスを再ロードする場合は、 「Web および EJB モジュールのクラス再ロード設定のオーバーライド」を選択してください。EJB モジュール、およびサーブレットや JSP ファイルなどの Web モジュールに対して、異なる値を指定する可能性があります。

  3. 更新されたファイルを探すためにアプリケーションのファイル・システムをスキャンする秒数を指定します。

    クラスの再ロードが使用可能になっている場合にのみ、「更新済みファイルのポーリング間隔」で指定した値が有効になります。 デフォルトは、エンタープライズ・アプリケーション (EAR ファイル) の IBM 拡張 (META-INF/ibm-application-ext.xmi) ファイルで指定されている再ロード間隔属性の値です。 EJB モジュール、およびサーブレットや JSP ファイルなどの Web モジュールに対して、異なる値を指定する可能性があります。

    再ロードを使用可能にするには、ゼロより大きい整数値 (例えば、1 から 2147483647 まで) を指定します。

    再ロードを使用不可にするには、ゼロ (0) を指定します。

  4. アプリケーションのクラス・ローダーの順序を指定します。

    アプリケーション・クラス・ローダーの順序で、クラス・ローダーが、クラスをロードする際に、最初に親クラス・ローダーを検索するのか、 アプリケーション・クラス・ローダーを検索するのかを指定します。 デフォルトでは、クラスをロードする際に、 親クラス・ローダーを検索してから、アプリケーション・クラス・ローダーを検索します。

    クラス・ローダー順序」で、以下の値のいずれかを選択します。

    オプション 説明
    最初に親クラス・ローダーでロードしたクラス クラス・ローダーが、クラスをロードする際に、 最初に親クラス・ローダーを検索することを指定します。この値は、Development Kit クラス・ローダーおよび WebSphere® Application Server クラス・ローダーの標準です。
    最初にローカル・クラス・ローダーでロードしたクラス (親が最後) クラス・ローダーが、クラスをロードする際に、 最初にアプリケーション・クラス・ローダーを検索することを指定します。最初にローカル・クラス・ローダーをロードしたクラス (親が最後) (Classes loaded with local class loader first (parent last)) を指定することにより、アプリケーションは親クラス・ローダーに含まれるクラスをオーバーライドできるようになります。
    重要:最初にローカル・クラス・ローダーをロードしたクラス (親が最後)」値を指定すると、オーバーライドされたクラスとオーバーライドされていないクラスを 混用した場合に、LinkageErrors または ClassCastException のメッセージが表示されることがあります。
  5. アプリケーションの Web アプリケーション・アーカイブ (WAR ファイル) をロードするために、 単一のクラス・ローダーを使用するのか、複数のクラス・ローダーを使用するのかを指定します。

    デフォルトで、 Web モジュールは独自の WAR クラス・ローダーを持ち、WEB-INF/classes および WEB-INF/lib の各ディレクトリーの内容をロードします。 デフォルトの WAR クラス・ローダー値は「アプリケーションの各 War ファイルのクラス・ローダー」で、それぞれの WAR ファイルをロードするために別々のクラス・ローダーが使用されます。 「アプリケーションの単一クラス・ローダー」にこの値を設定すると、アプリケーション・クラス・ローダーは、そのアプリケーションに関連付けられた EJB モジュール、共有ライブラリー、RAR ファイル、および依存関係 JAR ファイルだけでなく、Web モジュールの内容もロードします。 アプリケーション・クラス・ローダーは、WAR クラス・ローダーの親です。

    WAR クラス・ローダー・ポリシー」で、以下の値のいずれかを選択します。

    オプション 説明
    アプリケーションの各 War ファイルのクラス・ローダー 各 WAR ファイルに対して異なるクラス・ローダーを使用します。
    アプリケーションの単一クラス・ローダー 単一クラス・ローダーを使用して、 アプリケーションのすべての WAR ファイルをロードします。
  6. 「OK」をクリックします。

タスクの結果

アプリケーションまたはモジュール構成が変更されます。アプリケーションまたはスタンドアロンの Web モジュールを再始動すると、 変更が有効になります。

次のタスク

アプリケーションまたはモジュールがクラスターにデプロイされ、ほかに構成の変更を行わない場合は、「エンタープライズ・アプリケーション」ページの「更新のロールアウト」をクリックして、アプリケーションまたはモジュールがデプロイされているクラスターの全クラスター・メンバーに変更済み構成を伝搬します。 「更新のロールアウト」により、クラスター・メンバーが含まれるノード上で構成が順次更新されます。

管理構成の変更を保管します。

複数サーバー製品では、デプロイメント・マネージャーの構成変更がアプリケーションが稼働する個々のノード構成と同期する際に、アプリケーション・バイナリーがノードに転送されます。


トピックのタイプを示すアイコン タスク・トピック



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