ホット・デプロイメントと動的再ロード

サーバーの停止と再始動を行わなくとも、アプリケーションやそのモジュールにさまざまな変更を 加えることができます。 これらのタイプの変更は、 ホット・デプロイメントおよび動的再ロードと呼ばれます。

事前処理

以下の注記は、このトピック内の .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.xmi、 ibm-webservices-bnd.xmi、 ibm-webservicesclient-bnd.xmi、 ibm-webservicesclient-ext.xmi、および ibm-portlet-ext.xmi ファイルは、引き続き .xmi ファイル拡張子を使用します。

制約事項: 製品がこれらのオペレーティング・システムで実行されている場合、ホット・デプロイメントおよび動的再ロード機能はサポートされません。 関連付けられた Java Development Kit (JDK) 内の Java アーカイブ (JAR) ファイルは、メモリー・マップされます。 これらの JAR ファイルが、Java 仮想マシン (JVM) で使用中に ホット・デプロイメントと動的再ロード機能により更新されると、ファイルに不整合が生じ、アプリケーション・サーバーのクラッシュにつながります。 これらのオペレーティング・システム上のアプリケーションに変更を加えるときは、ホット・デプロイメントと動的再ロード機能は使用しないでください。 代わりに、アプリケーションを再始動して変更内容を反映してください。

このトピックでは、アプリケーション・ファイルがサーバーにデプロイされていること、 およびそれらのファイルをアップグレードする必要があることが前提となります。

エンタープライズ・アプリケーション・ファイルを更新する方法 を参照し、ホット・デプロイメントがアプリケーション・ファイルを更新するための適切な方法であるかどうかを判別してください。 他の方法のほうが簡単です。ホット・デプロイメントは経験者のみに適しています。

今後、アプリケーションのエクスポート、アプリケーション構成をベースにしたプラグインの生成、または他のアプリケーション管理を実行する予定の場合、ホット・デプロイメントは使用しないでください。 ホット・デプロイメントを使用してアプリケーション・ファイルに対して行う変更は、 管理コンソールや wsadmin アプリケーション管理機能では認識されません。 これらの機能は、コンソールや wsadmin などの管理プログラムが アプリケーションのインストール、更新、または他の管理機能を実行している間に表示する アプリケーション・ファイルしか認識しません。 アプリケーション管理機能は、ホット・デプロイメントによって 変更されたファイルを認識しません。

重要: 実動デプロイメント・マネージャーの管理対象セル内のコンポーネントを更新するためにホット・デプロイメントを使用しないでください。 ホット・デプロイメントは開発およびテストに適切ですが、実稼働環境に受諾不能なリスクをもたらします。 全体的再同期または部分的再同期によって、ホット・デプロイ・コンポーネントは消去される可能性があります。 また、restoreconfig コマンドを実行すると、 展開されたアプリケーション・ファイルに行った変更が上書きされる場合があります。 さらに、ホット・デプロイされたコンポーネントは、 WebSphere® Application Serverのバージョン間でマイグレーションされません。 新規コンポーネントまたはモジュールをエンタープライズ・アプリケーションに追加するには、 新規コンポーネントまたはモジュールを持つようにアプリケーション EAR ファイルを再アセンブルし、EAR ファイルを再デプロイします。

1. 拡張アプリケーション・ファイルを探し出します。

   アプリケーション・ファイルは、アプリケーションのインストール時に指定したディレクトリーにあります。カスタム・ターゲット・ディレクトリーを指定しなかった場合は、デフォルトのターゲット・ディレクトリー app_server_root/installedApps/cell_nameにあります。 EAR ファイル ${APP_INSTALL_ROOT}/cell_name/application_name.earは、ターゲット・ディレクトリーを指しています。 ノードの variables.xml ファイルは ${APP_INSTALL_ROOT}を定義します。

   アプリケーションのインストールの一環として、 WebSphere Application Server は、アプリケーションを実行するコンピューターのファイル・システムに EAR ファイルの一部を unjar するため、拡張されたアプリケーション・ファイルを見つけることが重要です。 これらの拡張ファイルは、アプリケーションの実行時にサーバーが参照するファイルです。 展開したアプリケーション・ファイルが見つからない場合は、アプリケーションの deployment.xml ファイル内の binariesURL 属性を確認します。 この属性には、ランタイムがアプリケーション・ファイルを検出するために使用するロケーションが指定されています。

   ホット・デプロイメントおよび動的再ロードでは、application_root は、 拡張アプリケーション・ファイルのルート・ディレクトリーを示していることに注意してください。

2. アプリケーション・メタデータ・ファイルを探し出します。 メタデータ・ファイルには、デプロイメント記述子 (web.xml、 application.xml、 ejb-jar.xmlなど)、バインディング・ファイル (ibm-web-bnd.xmi、 ibm-app-bnd.xmiなど)、および拡張ファイル (ibm-web-ext.xmiなど) が含まれます。 ibm-app-ext.xmi、およびそれに類似したもの)。

   アプリケーションのメタデータ XML ファイルは、2 つのロケーションのいずれかからロードできます。 メタデータ・ファイルは、アプリケーション・バイナリー・ファイルと同じ場所 ( application_root/META-INFなど) からロードすることも、 WebSphere 構成ツリー ${CONFIG_ROOT}/cells/cell_name/applications /application_EAR_name/deployments/application_name/からロードすることもできます。 アプリケーションのインストール時に指定した useMetadataFromBinary フラグの値が、 どのロケーションが使用されるのかを制御します。 この値が指定されている場合、メタデータ・ファイルは、 アプリケーションのバイナリー・ファイルと同じロケーションからロードされます。 この値が指定されていない場合、メタデータ・ファイルは、 構成ツリーにあるアプリケーション・デプロイメント・フォルダーからロードされます。

   重要: このトピックの手順に従って、 useMetadataFromBinaries=trueを使用したり、ホット・デプロイメントを使用して抽出したアプリケーションのコピーを変更したり、実行時に変更を有効にしたりすることができます。 ただし、ホット・デプロイメントを使用してアプリケーション・ファイルに対して行った変更は、 コンソールまたは wsadmin アプリケーション管理機能では認識されません。 これらの機能はオリジナルのアプリケーション・ファイルのみを認識し、 ホット・デプロイメントによって変更されたファイルは認識しません。 今後、アプリケーションのエクスポート、アプリケーション構成をベースにしたプラグインの生成、または他のアプリケーション管理を実行する予定の場合、ホット・デプロイメントは使用しないでください。 ホット・デプロイメントにより、アプリケーション・ファイルを素早く変更できますが、 ホット・デプロイメントでは、アプリケーションのライフ・サイクル全体の管理はサポートされません。

   この情報の残りの部分では、 metadata_root は、指定されたアプリケーションまたはモジュールのメタデータ・ファイルの場所を表します。

3. 必須: WebSphere Application Server Network Deployment を使用するマシンのグループで WebSphere Application Server を実行していて、特定のノード上のアプリケーションを変更する場合は、使用不可にしてください。 自動同期。
   1. コンソール・ナビゲーション・ツリーで システム管理 > ノード・エージェント > ノード・エージェント名 > ファイル同期サービス をクリックします。
   2. 「ファイル同期サービス」 ページで、 「自動同期」 のチェック・ボックスをクリアして、 「OK」をクリックします。

   WebSphere Application Server Network Deployment を使用してマシンのグループ上で WebSphere Application Server を実行し、特定のノードの拡張アプリケーション・ディレクトリー内のディスク上のファイルを変更すると、次にノード同期が行われるときにそれらの変更が失われる可能性があります。 WebSphere Application Server Network Deployment 環境では、デプロイメント・マネージャーによって保管される構成はマスター・コピーであり、そのマスター・コピーと特定のマシン上のコピーとの間で検出された変更により、マスター・コピーがノードにダウンロードされます。

4. オプション: アプリケーションのクラス・ローダーの設定ページで、 「アプリケーション・ファイルの更新時にクラスを再ロードする (Reload classes when application files are updated)」 および 「更新されたファイルのポーリング間隔 (Polling interval for updated files)」 に指定された値を調べます。

   クラスの再ロードが使用可能になっていて、ポーリング間隔がゼロ (0) より大きい場合、 アプリケーション・ファイルは、アプリケーションの更新後に再ロードされます。 Web モジュールの JavaServer Pages (JSP) ファイルの場合、Web コンテナーは ibm-web-ext.xmi ファイルの jspAttributes 内の IBM 拡張 jspReloadingEnabled が true に設定されている場合にのみ、JSP ファイルの再ロードを行います。 アセンブリー・ツールで Web モジュールの拡張デプロイメント記述子を編集する場合は、jspReloadingEnabled を true に設定することができます。

5. 必要に応じて、以下のコンポーネントまたはモジュールを変更または追加します。
   • アプリケーション・ファイル
   • WAR ファイル
   • EJB JAR ファイル
   • HTTP プラグイン構成ファイル
6. 変更内容を有効にするには、 アプリケーションを始動、停止、または再始動する必要がある場合があります。

   「 エンタープライズ・アプリケーションの開始または停止 」には、管理コンソールを使用したアプリケーションの開始、停止、または再始動に関する情報が記載されています。

   「 wsadmin スクリプトによるアプリケーションの開始 」および「 wsadmin スクリプトによるアプリケーションの停止 」には、wsadmin スクリプト・ツールの使用に関する情報が記載されています。

7. ステップ 3 で自動同期を使用不可にした場合は、 自動同期を再び使用可能にします。
   1. 「ファイル同期サービス」 ページに戻ります。
   2. 「自動同期」を選択します。
   3. 「OK」をクリックします。