サーバーの停止と再始動を行わなくとも、アプリケーションやそのモジュールにさまざまな変更を
加えることができます。このような種類の変更のことを、「ホット・デプロイメントと動的再ロード」といいます。
始める前に
以下の注記は、このトピック内の .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 ファイル拡張子
を使用します。
sptcfg
![[Solaris]](../images/solaris.gif)
制約事項: 製品をこれらのオペレーティング・システムで実行している場合は、ホット・デプロイメントと動的再ロード機能はサポートされません。関連する Java Development Kit (JDK) 内の Java アーカイブ (JAR) ファイルはメモリー・マッピングされています。これらの JAR ファイルが、Java 仮想マシン (JVM) で使用中に
ホット・デプロイメントと動的再ロード機能により更新されると、ファイルに不整合が生じ、アプリケーション・サーバーのクラッシュにつながります。これらのオペレーティング・システム上のアプリケーションに変更を加えるときは、ホット・デプロイメントと動的再ロード機能は使用しないでください。
代わりに、アプリケーションを再始動して変更内容を反映してください。
このトピックでは、ご使用のアプリケーション・ファイルがサーバー上にデプロイ済みで、そのファイルを更新することが前提となっています。
エンタープライズ・アプリケーション・ファイルの更新方法を参照して、
ホット・デプロイメントがアプリケーション・ファイルを更新する方法として適切かどうかを判別します。
他の方法のほうが簡単です。ホット・デプロイメントは経験者のみに適しています。
将来、アプリケーションのエクスポート、アプリケーション構成をベースにしたプラグインの生成、または他のアプリケーション管理を実行する予定の場合、ホット・デプロイメントは使用しないでください。
ホット・デプロイメントを使用してアプリケーション・ファイルに対して行う変更は、
管理コンソールまたはアプリケーション管理機能では認識されません。
これらの機能は、コンソールや wsadmin などの管理プログラムが
アプリケーションのインストール、更新、または他の管理機能の間に告知する
アプリケーション・ファイルしか認識しません。アプリケーション管理機能は、ホット・デプロイメントによって
変更されたファイルを認識しません。
重要: ホット・デプロイメントを用いて
、実動デプロイメント・マネージャーの管理対象セルでコンポーネントを更新しないでださい。
ホット・デプロイメントは開発およびテストに適切ですが、実稼働環境に受諾不能なリスクをもたらします。
全体的再同期または部分的再同期によって、ホット・デプロイ・コンポーネントは消去される可能性があります。
また、restoreconfig コマンドを実行すると、
展開されたアプリケーション・ファイルに行った変更が上書きされる場合があります。
さらに、ホット・デプロイ・コンポーネントは、WebSphere® Application Server のバージョン間では、
マイグレーションされません。
新規コンポーネントまたはモジュールをエンタープライズ・アプリケーションに追加するには、
新規コンポーネントまたはモジュールを持つようにアプリケーション EAR ファイルを再アセンブルし、EAR ファイルを再デプロイします。
このタスクについて
常時配置は、
新規コンポーネント (WAR ファイル、EJB Jar ファイル、Enterprise Java Beans、
サーブレット、JSP ファイルなど) を稼働中のサーバーに追加するプロセスで、
その際にアプリケーション・サーバー・プロセスを停止して再始動する必要はありません。
動的再ロードは、
既存のコンポーネントを変更する機能で、
変更を有効にするためにサーバーを再始動する必要はありません。
動的再ロードには、以下が含まれます。
- サーブレットの実装の変更など、
アプリケーションのコンポーネントの実装に対する変更。
- Web モジュールのデプロイメント記述子の変更など、アプリケーションの設定に対する変更。
エンタープライズ・アプリケーション・ファイルの更新で説明している、
デプロイされたアプリケーションの変更とは対照的に、
ホット・デプロイメントまたは動的再ロードを使用して行った変更は、管理コンソール
または wsadmin スクリプト・コマンドを使用しません。
アプリケーションがデプロイされるサーバー上で、
アプリケーションを直接操作する必要があります。
更新するアプリケーションが、アプリケーション・クラス・ローダー・ポリシーを Single に設定したサーバーにデプロイされている場合、
アプリケーションの動的な再ロードは行えません。少なくとも、アプリケーションを更新した後でサーバーを再始動する必要があります。
手順
- 拡張アプリケーション・ファイルを探し出します。
このアプリケーション・ファイルは、
アプリケーションのインストール時に指定したディレクトリーに配置されています。
カスタム・ターゲット・ディレクトリーが指定されていない場合は、デフォルトのターゲット・ディレクトリー、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 は、
拡張アプリケーション・ファイルのルート・ディレクトリーを示していることに注意してください。
- アプリケーション・メタデータ・ファイルを探し出します。
メタデータ・ファイルには、デプロイメント記述子 (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 は、
指定されたアプリケーションまたはモジュールのメタデータ・ファイルのロケーションを表していることに注意してください。
- 必須: WebSphere Application Server Network Deployment を使用しているマシンのグループで WebSphere Application Server が稼働中に特定のノードでアプリケーションを変更する場合は、
自動同期化は使用不可にしてください。
- コンソールのナビゲーション・ツリーで、の順にクリックします。
- 「ファイル同期サービス」ページで、
「自動同期」のチェック・ボックスをクリアし、「OK」をクリックします。
WebSphere Application Server Network Deployment を使用しているマシンのグループで
WebSphere Application Server を稼働させ、
特定のノードの拡張アプリケーション・ディレクトリーでディスク上のファイルを変更した場合、
次にノードの同期化が発生したときにこれらの変更が失われる可能性があります。WebSphere Application Server Network Deployment 環境では、デプロイメント・マネージャーによって保管された構成はマスター・コピーで、マスター・コピーと特定のマシン上のコピーの間で何か変更が検出されると、それがトリガーとなりマスター・コピーがノードにダウンロードされます。
- オプション: アプリケーションのクラス・ローダーの設定ページにある、
「アプリケーション・ファイルの更新時に、クラスを再ロードする」および「更新ファイルのポーリング間隔」で指定されている値を検査します。
クラスの再ロードが使用可能になっていて、ポーリング間隔がゼロ (0) より大きい場合、
アプリケーション・ファイルは、アプリケーションの更新後に再ロードされます。Web モジュールの JavaServer Pages (JSP) ファイルの場合、Web コンテナーは ibm-web-ext.xmi ファイルの jspAttributes 内の IBM 拡張 jspReloadingEnabled が true に設定されている場合にのみ、JSP ファイルの再ロードを行います。アセンブリー・ツールで Web モジュールの拡張デプロイメント記述子を編集する場合は、jspReloadingEnabled を true に設定することができます。
- 必要に応じて、以下のコンポーネントまたはモジュールを変更または追加します。
- 変更内容を有効にするには、
アプリケーションを始動、停止、または再始動する必要がある場合があります。
エンタープライズ・アプリケーションの開始または停止 では、管理コンソールを使用して
アプリケーションを始動、停止、または再始動する方法について説明しています。
wsadmin スクリプトによるアプリケーションの開始 および wsadmin スクリプトによるアプリケーションの停止 では、
wsadmin スクリプト・ツールの使用法について説明しています。
- ステップ 3 で自動同期を使用不可にした場合は、
自動同期を再び使用可能にします。
- 「ファイル同期サービス」ページに戻ります。
- 「自動同期」を選択します。
- 「OK」をクリックします。
タスクの結果
アプリケーション・ファイルは、サーバー上で更新されます。
サーバー上ではアプリケーション・ファイルを直接操作したので、
後に管理コンソールや wsadmin スクリプト・コマンドを使用してこれらのファイルを処理できない場合があります。
例えば、エンタープライズ・アプリケーションのコンソール・ページにある「エクスポート」を使用して、手動で変更したアプリケーションをエクスポートしようとすると、installedApps ディレクトリー内のアプリケーションに対して手動で行った変更はエクスポートされません。
これらの変更内容をエクスポートする場合は、アプリケーション・ファイルを手動でコピーし、移動する必要があります。