| Oracle Containers for J2EEデプロイメント・ガイド 10g（10.1.3.4.0） B50868-01 |
|
 戻る |
 次へ |
この章では、OC4Jのオートデプロイ機能について説明します。オートデプロイでは、アプリケーション内の変更されたファイルのみがOC4Jインスタンスに自動的にリロードされます。アプリケーション全体を再デプロイする必要はありません。
次の項目について説明します。
オートデプロイ、すなわちOC4Jポーリングは、現在デプロイされているアプリケーションやモジュールに加えられた変更を調べて、変更されたファイルを自動的にリロードするタスク管理機能です。この機能によって、コードの更新のたびにデプロイ・プロセスを繰り返す必要がなくなることから、開発者には大きな利点があります。
デフォルトでは、OC4Jはデプロイするファイルを1秒おきにチェックします。この間隔は、server.xml構成ファイルの<application-server>要素のtaskmanager-granularity属性で構成できます。タスク・マネージャ構成の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
OC4JでJ2EEアプリケーションを開発する場合、迅速なデプロイおよびテスト・サイクルを実現するために、展開ディレクトリのデプロイを使用できます。 展開ディレクトリのデプロイにより、エンタープライズ・アプリケーション・アーカイブ（EAR）またはWebアプリケーション・アーカイブ（WAR）ファイルにアプリケーションをパッケージすることなく、分散した一連の展開ディレクトリにアプリケーションをデプロイできます。
1つの展開ディレクトリがアプリケーションレベルのディレクトリを表し、残りはデプロイされるモジュールになります。 モジュール・ディレクトリは、アプリケーションレベル・ディレクトリの下位に配置できます。または、それ以外の場所に配置して、各モジュール・ディレクトリへの代替パスを指定できます。
自動ポーリングに加えて、admin.jarコマンドライン・ユーティリティには、更新済ファイルをOC4Jで強制的にチェックする-updateConfigオプションが含まれています。この機能を本番環境で使用すると、更新済ファイルのチェックとリロードを必要なときに行うことができます。この機能の詳細は、「admin.jarによる1回かぎりの再デプロイ強制実行」を参照してください。
展開ディレクトリのデプロイは、EARファイルにパッケージされたJ2EEアプリケーションのデプロイと同等であり、部分再デプロイをサポートすることでアプリケーションのテストを容易にします。 EARファイルをデプロイする場合、OC4JではEARのコピーが作成され、そのコピー内のファイルにアクセスすることでアプリケーションが実行されます。 展開ディレクトリのデプロイの場合、OC4Jではデプロイ・プランのみがコピーされ、ファイル・システム内の元のアプリケーション・ファイルにアクセスすることでアプリケーションが実行されます。
アプリケーションは、パッケージされたアプリケーション・アーカイブのかわりに、完全に展開された標準のディレクトリ構造からデプロイできます。 展開ディレクトリのデプロイでは、OC4Jにより、すべてのWebコンテンツ、クラス・ファイル、ライブラリ、デプロイメント・ディスクリプタなどが直接ファイル・システムから読み取られます。 この方法で、すべてのタイプの標準J2EEモジュールおよびアプリケーション（Webモジュール、EJBモジュールおよび完全なJ2EEアプリケーションを含む）をデプロイできます。 展開ディレクトリは、アプリケーションおよびコンポーネント向けの標準のJ2EEディレクトリ構造に準拠している必要があります。
OC4J構成ファイルのserver.xmlで、アプリケーション・ディレクトリへのパスを指定できます。 ただし、アプリケーションの各モジュールは、アプリケーションレベル・ディレクトリのサブディレクトリ内に存在する必要はありません。 モジュール・ディレクトリは、ファイル・システム内の他の場所に配置し、アプリケーションのapplication.xmlデプロイメント・ディスクリプタに各モジュールへの代替パスを指定できます。 また、代替パスは、OC4Jアプリケーション・デプロイメント・ディスクリプタのorion-application.xmlに指定することもできます。
アプリケーションの開発時に展開ディレクトリのデプロイを使用すると、クラスを迅速に変更、コンパイルおよび実行できます。 OC4Jでは、展開ディレクトリ形式で開発したアプリケーションが自動的にデプロイされます。
このオートデプロイは、アプリケーションレベル・ディレクトリ（図14-1のappnameのようなマスター・ディレクトリ）でタイムスタンプが変更されると常に実行されます。 マスター・ディレクトリのサブディレクトリ（マスター・ディレクトリ内に存在するか、ファイル・システム内の他の場所に存在）は、OC4Jでデプロイするアプリケーション・モジュールです。
展開ディレクトリのデプロイを実行するには、アプリケーションの初期デプロイ用にOC4J構成ファイルを変更する必要があります。 マスター・ディレクトリの場所は、OC4Jのserver.xml構成ファイルのpath属性の値です。 application.xmlおよび（オプションで）orion-application.xmlに各J2EEモジュールの代替パスを指定することで、OC4Jではモジュール・ディレクトリの場所を特定できます。 パス名の形式は、プラットフォームに依存します。 LinuxまたはUNIX環境では、パス名にスラッシュを含めることができます。 Windows環境では、パス名に円記号を含めることができます。 パス名の例は、次のとおりです。
D:\sharedfolder\My resource /scratch/sharedfolder/my resource
展開ディレクトリのデプロイでは、アプリケーションのマスター・ディレクトリと各モジュール・ディレクトリが、EAR、WARまたはJARファイルに必要とされる階層形式を保持している必要があります。 ディレクトリ・パスのセットがアプリケーションを表しており、マスター・ディレクトリを示す1つのパスと、それぞれがアプリケーション・モジュールの場所を示す1つ以上の代替パスが存在します。 図14-1は、マスター・ディレクトリappnameを含むJ2EEアプリケーションのディレクトリ構造を示しています。 appnameの下のディレクトリ構造は、EARファイル内の構造と同じです。
マスター・ディレクトリからJ2EEアプリケーションをビルドおよびデプロイする手順:
次のように、ファイルを任意のディレクトリまたはディレクトリ・セットに配置します。
各EJB JAR、WAR、クライアントJARおよびRARファイルの名前を、個別のモジュールを表す任意のディレクトリ名で置き換えます。
図14-1では、これらのディレクトリ名がejb_module/、web_module/、client_module/およびconnector_module/で表されています。
パッケージ構造にマップされる適切なディレクトリ構造内に各モジュールのクラスを配置します。
server.xmlファイルを編集し、デプロイされる展開ディレクトリへのパスを指定する新しい<application>要素を追加します。
次に例を示します。
<application name="dwp" path="file://d:/eclipse/workspace/dwp/test-app"/>
application.xmlおよび（オプションで）orion-application.xmlにJ2EEモジュールの絶対パスまたは相対パスをリストします。
j2ee/home/applications/appname/META-INF/application.xmlファイルで、<module>要素内の<web-uri>、<ejb>および<client>要素を変更し、各モジュールのディレクトリ・パス名（JARまたはWARファイル名ではありません）を指定します。 各モジュールが存在するディレクトリを指定する場合、これらの各要素のパス名は、マスター・ディレクトリを基準とする相対パスで表し、各アプリケーション・タイプのWEB-INFまたはMETA-INFディレクトリの親を指定する必要があります。
application.xmlとorion-application.xmlで同じJava EEモジュールを参照する場合、キーはパス指定です（絶対または相対、ディレクトリURLまたはアーカイブ・ファイルURL）。 キーは、両方のファイルで同一である必要があります（キーが含まれる場合）。
たとえば、次の<web-uri>要素では、<web>および<module>要素内でWebモジュール・ディレクトリとしてmyapp-web/を指定しています。
<module>
<web>
<web-uri>myapp-web</web-uri>
</web>
</module>
|
注意: OC4J 10g（10.1.3.4.0）では、j2ee/home/config/system-application.xmlファイルで示されるsystemアプリケーションがすべてのアプリケーションの最上位の親になります。 ただし、Webモジュールは、j2ee/home/config/application.xmlで示されるdefaultアプリケーションにデプロイすることをお薦めします。 |
j2ee/home/config/default-web-site.xmlファイルで、展開ディレクトリ内のWebアプリケーションごとに新しい<web-app>要素を追加します。
次に例を示します。
<web-app application="dwp" module="web" context-root="/dwp"/>
<web-app>要素により、アプリケーションがWebサイトにバインドされます。 <web-app>のapplication属性の値は、server.xmlファイルのアプリケーション名と同じである必要があります。 name属性の値は、application.xmlファイルの<web-uri>要素のパスのように、Webアプリケーションへのディレクトリ・パスである必要があります。
デプロイされるアプリケーションが展開WAR形式のスタンドアロンWebアプリケーションである場合、そのアプリケーションをスタンドアロンWebモジュールとしてdefaultアプリケーションにデプロイできます。
application.xmlファイルを編集し、デプロイされる展開ディレクトリへのパスを指定する新しい<web-module>要素を次のように追加します。
<web-module id="dwp" path="file://d:/eclipse/workspace/dwp/web"/>
default-web-site.xmlファイルを編集し、Webモジュールの新しい<web-app>要素を次のように追加します。
<web-app application="default" module="dwp" root="/dwp"/>
OC4Jが起動すると、アプリケーションとWebモジュールが、指定された展開ディレクトリ・パスからデプロイされます。
アプリケーション・モジュールから展開アプリケーション全体を作成することが可能です。これを行うには、application.xmlファイルをexploded-application.xmlファイルにクローニングし、不要なエントリを削除してからアプリケーションをserver.xmlに追加します。これにより、J2EEモジュールをdefaultアプリケーションの外部にある、起動、停止および管理可能な独自のアプリケーション内に維持できます。
展開ディレクトリにアプリケーションをクローニングする手順:
application.xmlファイルを、ORACLE_HOME/j2ee/instance/configディレクトリのexploded-application.xmlにコピーします。
>cd j2ee/home/config >cp application.xml exploded-application.xml
server.xmlを編集して次の要素を追加します。
<application name="exploded" path="exploded-application.xml" parent="default" start="true" />
exploded-application.xmlを編集して、不要なアプリケーション・モジュール（ほとんどのモジュール）を削除し、次のようにWebモジュールのエントリを追加します。
<web-module id="exp" path="d:/temp/exp/how-to-cluster-web" />
展開Webモジュールをexploded Webサイトにバインドします。
<web-app application="exploded" name="exp" load-on-startup="true" context-root="/exp" />
新規格納アプリケーションの名前がexplodedになったため、default Webサイトのかわりにexplodedを使用します。
展開ディレクトリのデプロイの使用時に、展開ディレクトリ構造でJavaServer Pages（JSP）モジュールを変更すると、デフォルトのOC4J設定によりその変更が認識され、ページが再コンパイルされます。 暗黙的なデフォルト設定のwith main_modeにより、OC4JではJSPモジュールに対する変更が検出されます。
変更済のJSPが再コンパイルされない場合、ブラウザがキャッシュからページをロードしないように、[Shift]を押しながら「更新」をクリックしてください。
Web Bean、DTO、DAOなど、JSPモジュールで使用されるコンパイル済のJavaクラスを変更した場合、OC4Jでは、JSPモジュールで変更済のクラスが検出されません。
展開ディレクトリから変更済クラスをリロードする手順:
server.xmlの<application-server>要素でcheck-for-updates属性をallに設定します。
<application-server
application-directory="../applications"
check-for-updates="all"
deployment-directory="../application-deployments"
connector-directory="../connectors"
schema-major-version="10" schema-minor-version="0" >
これで、展開ディレクトリで発生したクラスの変更がすべて検出されます。
check-for-updates属性の詳細は、「更新の確認機能の使用」を参照してください。
|
注意: JARファイルをデプロイする方が、より優れたパフォーマンスを得ることができます。 実行時には、JARファイル全体がメモリーにロードされ、索引付けされます。 この方法は、必要に応じて開発ディレクトリから各クラスを読み取るより高速です。 |
オートデプロイを開始するには、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の起動時にデフォルトでデプロイまたは再デプロイされます。
EARファイルまたはWARファイルは、そのタイムスタンプがファイルを格納するディレクトリのタイムスタンプより新しい場合にもデプロイされます。 |
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インスタンスのORACLE_HOME/j2ee/instance/configディレクトリ内のOC4J構成ファイルを変更した場合の影響を示します。
表14-2 OC4J構成ファイルの変更の影響
| 変更するファイル | 開始される処理 |
|---|---|
|
|
OC4Jサーバー構成ファイルを変更すると、OC4Jサーバーが再起動されます。 |
|
|
OC4JサーブレットやJSPコンテナの構成に使用されるこのファイルを変更すると、インスタンス内のすべてのWebサイトにバインドされているすべてのWebモジュールが強制的に再起動されます。 |
|
|
このOC4Jインスタンスのすべてのアプリケーションの共通設定を含むこのファイルを変更すると、デプロイされているすべてのアプリケーションが強制的に再起動されます。 |
|
|
Webサイト構成ファイルを変更すると、Webサイトが再起動されます。再起動中は受信リクエストが処理されません。 |
表14-3には、ORACLE_HOME/applicationsディレクトリにコピーされた更新済EARファイル内の1つ以上のデプロイメント・ディスクリプタの変更による影響を示します。
表14-4に、アプリケーションの一部としてデプロイされている更新済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構成および管理ガイド』を参照してください。
