サーバーの停止と再始動を行わなくとも、アプリケーションやそのモジュールにさまざまな変更を
加えることができます。このような種類の変更のことを、「ホット・デプロイメントと動的再ロード」といいます。
始める前に
このトピックでは、ご使用のアプリケーション・ファイルがサーバー上に
デプロイ済みで、そのファイルを更新することが前提となっています。
アプリケーション・ファイルの更新方法
を参照して、
ホット・デプロイメントがアプリケーション・ファイルを更新する方法として適切かどうかを判別します。
他の方法のほうが簡単です。ホット・デプロイメントは経験者のみに適しています。
このタスクについて
常時配置は、
新規コンポーネント (WAR ファイル、EJB Jar ファイル、Enterprise Java Beans、
サーブレット、JSP ファイルなど) を稼働中のサーバーに追加するプロセスで、
その際にアプリケーション・サーバー・プロセスを停止して再始動する必要はありません。
動的再ロードは、
既存のコンポーネントを変更する機能で、
変更を有効にするためにサーバーを再始動する必要はありません。
動的再ロードには、以下が含まれます。
- サーブレットのインプリメンテーションの変更など、
アプリケーションのコンポーネントのインプリメンテーションに対する変更。
- Web モジュールのデプロイメント記述子の変更など、
アプリケーションの設定に対する変更。
J2EE アプリケーションの更新
で説明している、
デプロイされたアプリケーションの変更とは対照的に、
ホット・デプロイメントまたは動的再ロードを使用して行った変更は、管理コンソール
または 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 フラグの値が、
どのロケーションが使用されるのかを制御します。
この値が指定されている場合、メタデータ・ファイルは、
アプリケーションのバイナリー・ファイルと同じロケーションからロードされます。
この値が指定されていない場合、メタデータ・ファイルは、
構成ツリーにあるアプリケーション・デプロイメント・フォルダーからロードされます。
metadata_root は、
指定されたアプリケーションまたはモジュールのメタデータ・ファイルのロケーションを表していることに注意してください。
- オプション: エンタープライズ・アプリケーションのページの設定で「クラスの再ロードを使用可能にする」および「Reloading interval」に指定した値を調べます。
アプリケーション・ファイルの再ロードが使用可能になっていて、再ロード間隔がゼロ (0) より大きい場合、
アプリケーション・ファイルは、アプリケーションの更新後に再ロードされます。
サーブレットや JavaServer Pages (JSP) ファイルなどの Web モジュールの場合、Web コンテナーは、ibm-web-ext.xmi ファイルの IBM 拡張 reloadingEnabled が true に設定されているときにだけ、Web モジュールの再ロードを行います。
アセンブリー・ツールで
Web モジュールの拡張デプロイメント記述子を編集する場合は、reloadingEnabled を true に
設定することができます。
- 必要に応じて、以下のコンポーネントまたはモジュールを変更または追加します。
- 変更内容を有効にするには、
アプリケーションを始動、停止、または再始動する必要がある場合があります。
J2EE アプリケーションの開始または停止
では、管理コンソールを使用してアプリケーションを始動、停止、または再始動する方法について説明しています。
スクリプトによるアプリケーションの開始
およびスクリプトによるアプリケーションの停止
では、wsadmin スクリプト・ツールの使用法について説明しています。
結果
アプリケーション・ファイルは、サーバー上で更新されます。
サーバー上ではアプリケーション・ファイルを直接操作したので、
後に管理コンソールや wsadmin スクリプト・コマンドを使用してこれらのファイルを処理できない場合があります。
例えば、エンタープライズ・アプリケーションのコンソール・ページにある
「エクスポート」を使用して、手動で変更したアプリケーションを
エクスポートしようとすると、installedApps ディレクトリー内のアプリケーションに対して
行った手動変更はエクスポートされません。これらの変更内容をエクスポートする場合は、アプリケーション・ファイルを手動でコピーし、移動する必要があります。