| Oracle Containers for J2EEデプロイメント・ガイド 10g（10.1.3.1.0） B31850-01 |
|
 戻る |
 次へ |
この章では、OC4Jのオートデプロイ機能について説明します。オートデプロイでは、アプリケーション内の変更されたファイルのみがOC4Jインスタンスに自動的にリロードされます。アプリケーション全体を再デプロイする必要はありません。
次の項目について説明します。
オートデプロイ、すなわちOC4Jポーリングは、現在デプロイされているアプリケーションやモジュールに加えられた変更を調べて、変更されたファイルを自動的にリロードするタスク管理機能です。この機能によって、コードの更新のたびにデプロイ・プロセスを繰り返す必要がなくなることから、開発者には大きな利点があります。
デフォルトでは、OC4Jはデプロイするファイルを1秒おきにチェックします。この間隔は、server.xml構成ファイルの<application-server>要素のtaskmanager-granularity属性で構成できます。タスク・マネージャ構成の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
自動ポーリングに加えて、admin.jarコマンドライン・ユーティリティには、更新済ファイルをOC4Jで強制的にチェックする-updateConfigオプションが含まれています。この機能を本番環境で使用すると、更新済ファイルのチェックとリロードを必要なときに行うことができます。この機能の詳細は、「admin.jarによる1回かぎりの再デプロイ強制実行」を参照してください。
オートデプロイは、開発環境のスタンドアロンOC4Jインスタンスに対してのみ使用してください。本番環境での使用はお薦めしません。
理由は、ポーリング・メカニズムがタスク・マネージャによって定期的に起動され、システム・リソースが使用されるためです。また、オートデプロイによってOC4Jの一貫性が失われる危険があり、リクエストがOC4Jに対する実行を試行した場合にエラーが発生することがあります。
オートデプロイを開始するには、EARファイルをOC4Jインスタンス内の指定のauto-deploymentディレクトリにドロップします。この機能はスタンドアロンOC4J開発環境のみで使用してください。
このディレクトリは、OC4Jインスタンスのホストであるサーバーに作成する必要があります。OC4Jで自動的に作成されることはありません。OC4J内の既存のディレクトリ（ORACLE_HOME/j2ee/instance/applicationsなど）を使用することもできます。
次に、ディレクトリの場所をapplication-auto-deploy-directory属性に指定する必要があります。これは、ORACLE_HOME/j2ee/instance/config/server.xmlのルートの<application-server>要素に追加してください。
次に示すserver.xmlのエントリでは、ORACLE_HOME/j2ee/instance/applicationsがオートデプロイ・ディレクトリとして設定されます。
<application-server ...
application-directory="../applications" check-for-updates="adminClientOnly"
deployment-directory="../application-deployments"
application-auto-deploy-directory="../applications">
...
</application-server>
|
注意: 更新の確認機能が有効にならない場合は、OC4Jを再起動して、server.xmlの構成の変更を有効にする必要があります。 |
構成が終了すると、タスク・マネージャが実行されるたびに、OC4Jがこのディレクトリをポーリングして新しいEARファイルまたは更新されたEARファイルを調べます。サーバーはEARファイルのタイムスタンプを比較して、再デプロイを開始するかどうかを判別します。再デプロイが必要な場合は、EARが自動的にデプロイされます。EARにWARファイルとしてパッケージされているWebモジュールがあれば、default Webサイトに自動的にバインドされます。
オートデプロイ・ディレクトリの機能は、OC4Jポーリングからは完全に独立しています。このディレクトリにドロップされたアーカイブは、OC4Jポーリングが有効か無効かに関係なくデプロイされます。
更新の確認機能を使用して、ファイルをOC4Jインスタンスに再デプロイできます。次の項目について説明します。
|
注意: ORACLE_HOME/j2ee/instance/applicationsディレクトリにコピーされたEARファイルまたはWARファイルは、オートデプロイが有効かどうかに関係なく、OC4Jの起動時にデフォルトでデプロイまたは再デプロイされます。 |
ORACLE_HOME/j2ee/instance/config/server.xmlのルート<application-server>要素のcheck-for-updates属性。次に例を示します。
<application-server ... check-for-updates="all" ... />
oc4j.jarコマンドラインでのcheckForUpdatesシステム・プロパティの設定。次に例を示します。
java -DcheckForUpdates=all -jar oc4j.jar
|
注意: 次の注意事項が、checkForUpdatesシステム・プロパティに適用されます。
|
表14-1に、いずれかの方法を使用してcheckForUpdatesに設定できる値を示します。
表14-1 checkForUpdatesの有効な値
| 値 | 説明 |
|---|---|
|
|
OC4Jポーリングを有効にします。ポーリングは、OC4Jタスク・マネージャの構成で指定された間隔で自動的に開始します。デフォルトの間隔は1秒です。 このオプションは、Oracle Application Serverまたは本番環境では使用しないでください。 この値を指定すると、 この機能の詳細は、「admin.jarによる1回かぎりの再デプロイ強制実行」を参照してください。 |
|
|
これは、スタンドアロンOC4JインストールとOracle Application Serverインストールの両方で設定されるデフォルト値です。 この機能の詳細は、「admin.jarによる1回かぎりの再デプロイ強制実行」を参照してください。 |
|
|
|
OC4Jインスタンスに自動的に再デプロイできるのは次のファイルです。
ORACLE_HOME/j2ee/instance/configディレクトリにある、変更されたOC4J固有のXML構成ファイル（server.xmlなど）。
ORACLE_HOME/j2ee/instance/applicationsディレクトリにコピーされている、更新済EARファイルにパッケージされた変更済デプロイメント・ディスクリプタ。
更新済WARファイルにパッケージされている次のファイル。WARは、ORACLE_HOME/j2ee/instance/applications/ディレクトリにコピーされたEARファイルにパッケージされている場合と、WebモジュールのORACLE_HOME/j2ee/instance/applications/webAppNameディレクトリに直接コピーされている場合があります。
変更されたデプロイメント・ディスクリプタ
WAR内のWEB-INF/lib/パスまたはWEB-INF/classes/*パスにある更新されたファイル
更新されたJSPタグ・ライブラリ（TLD）ファイル
|
注意: 現在、この機能では、EJBまたはデータ・ソース関連の構成の変更は自動的に検出されません。たとえば、EJB JARファイル内の変更されたファイルは自動的に再デプロイされません。このような構成の変更を検出して適切に適用するためには、OC4Jを再起動する必要があります。 |
次の表に、checkForUpdatesをallに設定して機能を有効にした場合の、様々なファイルの変更や更新による影響を示します。OC4Jポーリングを有効にする方法は、「更新の確認の有効化または無効化」を参照してください。
表14-2「OC4J構成ファイルの変更の影響」に、OC4JインスタンスのORACLE_HOME/j2ee/instance/configディレクトリ内のOC4J構成ファイルを変更した場合の影響を示します。
表14-2 OC4J構成ファイルの変更の影響
| 変更するファイル | 開始される処理 |
|---|---|
|
|
OC4Jサーバー構成ファイルを変更すると、OC4Jサーバーが再起動されます。 |
|
|
OC4JサーブレットやJSPコンテナの構成に使用されるこのファイルを変更すると、インスタンス内のすべてのWebサイトにバインドされているすべてのWebモジュールが強制的に再起動されます。 |
|
|
このOC4Jインスタンスのすべてのアプリケーションの共通設定を含むこのファイルを変更すると、デプロイされているすべてのアプリケーションが強制的に再起動されます。 |
|
|
Webサイト構成ファイルを変更すると、Webサイトが再起動されます。再起動中は受信リクエストが処理されません。 |
表14-3「EAR内のファイルの変更の影響」には、ORACLE_HOME/applicationsディレクトリにコピーされた更新済EARファイル内の1つ以上のデプロイメント・ディスクリプタの変更による影響を示します。
表14-4「WAR内のファイルの変更の影響」に、アプリケーションの一部としてデプロイされている更新済WARファイル内のファイルまたはデプロイメント・ディスクリプタの変更による影響を示します。更新済WARファイルは、EARにパッケージされている場合と、WebモジュールのORACLE_HOME/j2ee/instance/applications/webAppNameディレクトリにコピーされている場合があります。
OC4Jは、各ファイルのタイムスタンプを調べて、タイムスタンプが他と異なるファイルのみを再デプロイします。
表14-4 WAR内のファイルの変更の影響
| 変更するファイル | 開始される処理 |
|---|---|
|
|
更新済WARファイル内のJ2EE標準Webデプロイメント・ディスクリプタまたはOC4J固有のディスクリプタを変更すると、Webモジュールが新しい構成で再起動されます。 |
|
|
このパスのライブラリJARファイルを更新すると、強制的にWebモジュールが再起動され、変更されたクラスがリロードされます。 |
|
|
このパスのファイルを更新すると、強制的にWebモジュールが再起動され、変更されたクラスがリロードされます。 |
|
|
TLDファイルを更新すると、強制的にWebモジュールが再起動されます。 |
admin.jarコマンドライン・ユーティリティを使用して、スタンドアロンOC4Jインスタンスを管理できます。このツールには、必要なときにOC4Jポーリングを有効にする-updateConfigオプションが含まれます。これにより、ディレクトリで更新済ファイルが強制的にチェックされ、変更されたファイルがリロードされます。
|
使用上の注意:
|
ユーティリティはデフォルトでORACLE_HOME/j2ee/instanceにインストールされます。このユーティリティを使用するにはOC4Jサーバーが起動済である必要がありますが、デプロイ前にdata-sources.xmlファイルを変換した場合は例外です。
このコマンドの構文は次のとおりです。
java -jar admin.jar ormi://host:ormiPort adminId adminPassword -updateConfig
次の例では、oc4jOrmiPortに指定する値はデフォルトの23791です。adminIdに指定するユーザー名は、デフォルトの管理者アカウントのユーザー名oc4jadminです。
cd ORACLE_HOME\j2ee\instance java -jar admin.jar ormi://localhost:23791 oc4jadmin password -updateConfig
admin.jarユーティリティの使用方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
