アプリケーション・サーバー上の Web アプリケーション・アーカイブ (WAR ファイル) は、
サーバーを停止して、再始動することなく、変更することができます。
このタスクについて
サーバーを停止および再始動しなくても、WAR ファイルに加えることができる変更が
いくつかあります。
重要: アプリケーション・ファイルの更新方法
を参照して、
ホット・デプロイメントが WAR ファイルを更新する方法として適切かどうかを判別します。
他の方法のほうが簡単です。ホット・デプロイメントは経験者のみに適しています。
場合によっては、管理コンソールの
更新ウィザードを使用して、
サーバーを停止および再始動せずに変更を加えることができます。
次の表は、アプリケーションがデプロイされるサーバー上で WAR ファイルを操作することによって可能となる変更をリストしています。
また、この表はホット・デプロイメントまたは動的再ロードを使用して変更するかどうかも示しています。
プロシージャー
- 既存の JavaServer Pages (JSP) ファイルを変更します。
application_root/module_name ディレクトリーまたは該当するサブディレクトリーに、
変更済み JSP ファイルを直接配置します。
この変更は自動的に検出され、JSP ファイルの再コンパイルと再ロードが行われます。
- 既存のアプリケーションへ新規 JSP ファイルを追加します。
application_root/module_name ディレクトリーまたは該当するサブディレクトリーに、
新規 JSP ファイルを直接配置します。
新規ファイルは自動的に検出され、ページに対し最初に要求を送信した時点でコンパイルされます。
- 既存のサーブレット・クラスを
編集および再コンパイルすることによって変更します。
- application_root/module_name/WEB-INF/classes ディレクトリーに、
新バージョンのサーブレット .class ファイルを直接配置します。
.class ファイルが JAR ファイルに含まれる場合、
新バージョンの JAR ファイルは application_root/module_name/WEB-INF/lib に直接配置できます。
いずれの場合も、
この変更が検出され、Web アプリケーションのシャットダウンと再初期化が行われて、
新規クラスが選別されます。
- 自動再ロードが使用不可になっている場合は、アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。
自動再ロードが使用可能になっている場合は、これ以上のアクションは必要ありません。
自動再ロードを行なうと変更が検出されます。
- 既存のサーブレット・クラスの従属クラスを変更します。
- application_root/module_name/WEB-INF/classes ディレクトリーに、
新バージョンの従属 .class ファイルを直接配置します。
.class ファイルが JAR ファイルに含まれる場合、
新バージョンの JAR ファイルは application_root/module_name/WEB-INF/lib に直接配置できます。
いずれの場合も、
この変更が検出され、Web アプリケーションのシャットダウンと再初期化が行われて、
新規クラスが選別されます。
- 自動再ロードが使用不可になっている場合は、アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。
自動再ロードが使用可能になっている場合は、これ以上のアクションは必要ありません。
自動再ロードを行なうと変更が検出されます。
- Invoker (クラス名ごとにサーブレットを提供する) 機能を使用した新規サーブレットを追加するか、
または既存のアプリケーションへ従属クラスを追加します。
- application_root/module_name/WEB-INF/classes ディレクトリーに、新規の .class ファイルを直接配置します。
.class ファイルが JAR ファイルに含まれる場合、
新バージョンの JAR ファイルは application_root/module_name/WEB-INF/lib に直接配置できます。
いずれの場合も、
この変更が検出され、Web アプリケーションのシャットダウンと再初期化が行われて、
新規クラスが選別されます。
この場合は、既存クラスの変更と同じように扱われます。
この違いは、このクラスが以前にロードされていないために、
サーブレットまたはクラスを追加しても Web アプリケーションが再ロードをすぐには行わないという点にあります。
クラスは、実行する場合にのみ使用可能となります。
- 自動再ロードが使用不可になっている場合は、アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。
自動再ロードが使用可能になっている場合は、これ以上のアクションは必要ありません。
自動再ロードを行なうと変更が検出されます。
- 新規サーブレットを追加します (アプリケーションの web.xml デプロイメント記述子へのサーブレットの新規定義を含む)。
- application_root/module_name/WEB-INF/classes ディレクトリーに、新規の .class ファイルを直接配置します。
.class ファイルが JAR ファイルに含まれる場合、
新バージョンの JAR ファイルは application_root/module_name/WEB-INF/lib に直接配置できます。
所定の位置にある web.xml ファイルを編集することも、
そのファイルを application_root/module_name/WEB-INF/classes ディレクトリーにコピーすることもできます。
新規 .class ファイルからアプリケーションの再ロードは起動されません。
- アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。アプリケーションの再始動後、新規サーブレットをサービスに利用できるようになります。
- WAR ファイルの web.xml ファイルを変更します。
- 所定の位置にある web.xml ファイルを編集するか、
そのファイルを metadata_root/module_name/WEB-INF ディレクトリーにコピーします。
- アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。
- WAR ファイルの ibm-web-ext.xmi ファイルを変更します。
必要に応じて拡張設定を編集します。
拡張設定はすべて変更することができます。唯一注意が必要なのは、reloadInterval プロパティーをゼロ (0) に設定するか、
reloadEnabled プロパティーを false に設定すると、アプリケーションは、クラス・ファイルに対する変更を自動的には
検出しなくなるという点です。
これらの変更はいずれも自動再ロード機能を使用できないようにします。
自動再ロードを再度、使用できるようにする唯一の方法は、
該当するプロパティーを変更して、アプリケーションを再始動することです。
アプリケーションの再始動については、
このファイルの他のタスクの説明を参照してください。
- WAR ファイルの ibm-web-bnd.xmi ファイルを変更します。
- 必要に応じてバインディングを編集します。
すべての値を変更できますが、
バインディング先のエンティティーがサーバーの構成に存在することを確認してください。
- アプリケーションを再始動します。
管理コンソールを使用して、アプリケーションを再始動します。
または、wsadmin ツールで AdminControl オブジェクトの startApplication 属性および stopApplication
属性を使用します。