| Oracle Containers for J2EEデプロイメント・ガイド 10g（10.1.3.1.0） B31850-01 |
|
 戻る |
 次へ |
この章では、EARファイルにパッケージされたJ2EEアプリケーションのOC4Jインスタンスへのデプロイと、OC4JインスタンスからのJ2EEアプリケーションのアンデプロイを説明します。次の項目について説明します。
OC4Jでは、効率のよいユーザーフレンドリなデプロイメント・プロセスが提供されます。J2EE準拠のEARファイルはそのままでデプロイでき、変更や再パッケージは不要です。EARファイルの場所を指定するだけで、OC4Jによって、EJB JARやWARファイルなど、アプリケーションを構成するモジュールが自動的にデプロイされます。
次の項では、EARをOC4Jにデプロイするときに実行する一般的な手順を示します。
|
注意: 読取り専用共有ディレクトリからのEARのデプロイは、エラーが発生することがあるため、お薦めしません。EARファイルをまずローカル・ディレクトリにコピーしてからデプロイしてください。 |
OC4Jにデプロイされるすべてのアプリケーションには、親アプリケーションを指定する必要があります。デフォルトの親は、OC4Jに含まれる、defaultという名前のグローバル・アプリケーションです。
あるアプリケーションを親として指定すると、その子アプリケーションの間でクラスやサービスを共有できます。子アプリケーションは、親アプリケーションのネームスペースを参照して、親がインポートした一連の共有ライブラリを継承します。構成データも親からインポートされますが、子アプリケーションレベルでオーバーライドすることができます。
一旦アプリケーションをデプロイすると、子アプリケーション内のすべてのメソッドは親アプリケーション内のすべてのメソッドを起動できます。この方法により、1つのJAR内のメソッドが、別のJARにデプロイされているEJBを見られるようになります。これは、1つのJARファイルにすべてのサービスEJBをデプロイするときに役立ちます。この場合は、JARファイルのユーザーがサービス・アプリケーションを親として宣言します。
J2EEアプリケーションの一部としてデプロイするWebアプリケーションは、アプリケーションのアクセスに使用されるWebサイトにバインドする必要があります。このバインドは、Webアプリケーションのバインド先Webサイトを定義するname-web-site.xml構成ファイルのname部分を指定して行います。
ほとんどの場合、アプリケーションはデフォルトのWebサイトにバインドされます。このWebサイトは、default-web-site.xml構成ファイルで定義され、ポート8888でリクエストをリスニングします。default-web-site.xmlを含むすべてのWebサイト構成ファイルは、ORACLE_HOME/j2ee/instance/configディレクトリに格納されています。
Webモジュール・コンテキスト・ルート（Webブラウザを介してアプリケーションにアクセスするためにURLの最後に付ける）も、このWebアプリケーション有効化プロセスで設定されます。通常、この値はアプリケーションにパッケージされたapplication.xmlデプロイメント・ディスクリプタから読み取られます。
Oracle HTTP Serverが使用されている場合、コンテキスト・ルート値は、受信Webリクエストを適切なOC4Jインスタンスにルーティングするためのマウント・ポイント定義で使用されるので注意してください。詳細は、「Oracle Application Serverでの動的HTTPサーバーのマウント・ポイントの使用方法」を参照してください。
Oracle Enterprise Manager 10g Application Server Controlコンソールを介してデプロイする場合は、デプロイ・プロセスの最後の段階でデプロイ・プランを適用します。これは、アーカイブをOC4Jにデプロイするために必要なすべての構成データをクライアント・サイドで集約したものです。アプリケーションのために新しいデプロイ・プランを作成するか、既存のプランを再利用することができます。再利用は、再デプロイの際には特に有効です。
デプロイ・プランの作成と使用の詳細は、第8章「デプロイ・プランについて」を参照してください。
Oracle HTTP Server（OHS）が使用される構成では、WebリクエストはOHSインスタンス経由で受信されてから、リクエスト対象のアプリケーションを提供するOC4Jインスタンスにルーティングされます。
リクエストをルーティングするために、OHSはアプリケーション固有のマウント・ポイントのリストを利用します。このリストでは、リクエストに指定されたURLと、リクエストの処理を行うOC4Jインスタンスがマップされます。
Oracle Application Server 10gリリース3（10.1.3.0.0）以前は、このようなアプリケーション固有のマウント・ポイントの構成はすべて手動で行っていました。新しいアプリケーションがOC4Jインスタンスにデプロイされると、新しいマウント・ポイントをmod_oc4j.conf（リクエストをOC4Jインスタンスに転送するOHSのmod_oc4jモジュールの構成ファイル）に手動で追加することが必要でした。この後でOHSインスタンスを再起動する必要がありました。
Oracle Application Server 10gリリース3（10.1.3.1.0）ではマウント・ポイント構成は完全に自動化されており、手動でのファイル構成やOHSの再起動は必要ありません。クラスタ・トポロジ内のすべてのOC4Jインスタンスは、デプロイされたアプリケーションごとにマウント・ポイント・データをOHSに送信し、OHSがこの情報を内部ルーティング表に追加します。
新しいアプリケーションがOC4Jインスタンスにデプロイされると、マウント・ポイント情報はOHSに送信され、OHSが動的にアプリケーションを検出できます。マウント・ポイント情報の内容を次に示します。
OC4Jホスト・アドレス
Apache JServ Protocol（AJP）リスナー・ポート
この値は、OC4Jノードのopmn.xmlファイルでAJPに割り当てられている使用可能なポートのうち最も小さな値です。
Webアプリケーション名
この値は、アプリケーションがバインドされるWebサイトの*-web-site.xml構成ファイルで定義されます。
アプリケーションに対して定義されたWebコンテキスト
この値も*-web-site.xml構成ファイルで設定されます。
マウント・ポイント通知の送受信は、Oracle Process Manager and Notification Server（OPMN）のコンポーネントであるOracle Notification Server（ONS）によって管理されます。OPMNは、Oracle Application Server構成のすべてのOC4JおよびOHSインスタンスにデフォルトでインストールされています。
EARファイル内にパッケージされたアプリケーションをOC4Jにデプロイするときは、次の処理が行われます。
アプリケーションが再デプロイされる場合は、まず、既存のインストールがOC4Jからアンデプロイされます。
OC4JはEARファイルをデプロイ・ディレクトリにコピーします。デフォルトではORACLE_HOME/j2ee/instance/applicationsディレクトリです。
OC4Jは、EARファイルにパッケージされたapplication.xmlファイルを開いて解析します。このファイルは、EARファイルに含まれるすべてのモジュールをリストする標準J2EEディスクリプタです。OC4Jはこれらのモジュールを確認して、EAR環境を初期化します。
OC4Jは、モジュール・タイプ（Webモジュール（WAR）、EJBモジュール、コネクタ・モジュールまたはクライアント・モジュール）ごとにモジュール・デプロイメント・ディスクリプタをメモリーに読み取ります。JARファイルおよびWARファイルの環境も初期化されます。
OC4Jは、J2EEデプロイメント・ディスクリプタとOC4J固有のデプロイメント・ディスクリプタの両方に含まれる構成の詳細に反応します。OC4Jは、OC4Jによるアクション（インタフェースによるEJBのラップなど）を必要とするJ2EEコンポーネントの構成を確認します。
OC4Jは、デプロイ・プランの内容に従って、OC4J固有の新しい構成ファイルをORACLE_HOME/j2ee/instance/application-deployments/app_nameディレクトリに書き込みます。OC4J固有のデプロイメント・ディスクリプタが1つ以上指定された場合、生成されるファイルにOC4Jが要素を追加しています。
生成されるクラス（EJBインタフェース・ラッパー・クラスなど）は、コンパイルされて、このディレクトリの新しいサブディレクトリに格納されます。たとえば、EJBラッパー・クラスは、ORACLE_HOME/j2ee/instance/application-deployments/app_name/jar_name.jarディレクトリ内のdeployment-cache.jarという名前のアーカイブに生成されます。このときjar_name.jarは、デプロイされたEJB JARの名前に対応します。
最後に、OC4Jは、このアプリケーションがデプロイされたことを示す情報でOC4J server.xml構成ファイルを更新します。
JDK 1.5（Java 5）を稼働中のOC4Jにアプリケーション（OC4Jデフォルト・アプリケーションを含む）をデプロイする際、JDK 1.4を稼働中のOC4J上のデプロイは再利用できません。
JDK 1.5（Java 5）でコンパイルされたコードはJDK 1.4のVMでは読取りできません。JDK 1.4で稼働中のOC4JがJDK 1.5でコンパイルされたクラスをロードしようとすると、クラス・ロード例外が次のメッセージとともにスローされます。
Unsupported major.minor version 49.0
これは次のようなケースで発生します。
JDK 1.5を稼働中のOC4JにEJBを含むアプリケーションをデプロイし、次に、アプリケーションをアンデプロイせずにJDK 1.4を稼働中のOC4Jを再起動した場合。問題は、EJBに関連して生成されたコードが、サーバーの起動に使用されたのと同じJDKバージョンでコンパイルされ、生成されたコードがサーバーの再起動間にORACLE_HOME/j2ee/home/application-deploymentsディレクトリのファイル・システム上にキャッシュされることです。
この問題を回避するには、サーバーをシャットダウンし、ORACLE_HOME/j2ee/home/application-deploymentsディレクトリまたはアプリケーションのサブディレクトリのいずれかの内容を削除し、サーバーをJDK 1.4で再起動します。
JDK 1.5でコンパイルされ、JDK 1.5をターゲットとしたクラスを含むEARファイルを、JDK 1.4を稼働中のOC4Jにデプロイした場合。
この問題を回避するには、JDK 1.4を使用してEARの内容を再コンパイルし、再デプロイします。
|
注意: 説明を単純化するため、コードを特定のJDKバージョン向けにするため、クロスコンパイルは使用されていないことが前提となっています。 |
次の例は、ターゲット・ディレクトリがデフォルト設定と仮定して、utility.earという名前のアーカイブがデプロイされたときに作成される展開ディレクトリ構造の重要な部分を示します。EARには、Webモジュール（utility_web.war）と、1つのステートフル・セッションEJBを含むEJB JAR（utility_ejb.jar）があります。
OC4Jは、標準J2EEの内容とOC4J固有のファイルを、展開ディレクトリ構造内で明確に区別します。元のアーカイブと標準J2EEディスクリプタはj2ee/instance/applicationsディレクトリにコピーされ、これらのファイルはアプリケーションの再デプロイに使用できます。デプロイ時に生成されるOC4J固有のディスクリプタは、/j2ee/instance/application-deploymentsディレクトリに書き込まれます。
また、EJBラッパー・クラスUtilityManager_StatefulSessionBeanWrapper.classがdeployment-cache.jarアーカイブに生成されていることにも注意してください。デプロイ時に、OC4Jによって、EJB JARにパッケージされた各EJBに対するラッパー・クラスが生成されます。EJB JAR内のEJBに対して生成されたラッパー・クラスは、deployment-cache.jarという名前のアーカイブに含まれます。このアーカイブは、デプロイされたEJB JARと同じ名前で生成されるJARファイルに含まれます。
j2ee/oc4j1/
application-deployments/
utility/
orion-application.xml
utility_web/
orion-web.xml
utility_ejb.jar/
orion-ejb-jar.xml
deployment-cache.jar/
UtilityManager_StatefulSessionBeanWrapper.class
applications/
utility.ear
utility/
utility_web.war
utility_ejb.jar
META-INF/
application.xml
utility_web/
index.html
META-INF/
WEB-INF/
web.xml
classes/
Example.class
EARファイルにパッケージされたJ2EEアプリケーションの再デプロイでは、J2EEアプリケーションの前のインスタンスがOC4Jによってアンデプロイされます。アプリケーションにパッケージされている埋込みリソース・アダプタがあれば、それもアンデプロイされます。このため、再デプロイの前にアプリケーションをアンデプロイする必要はありません。
前のデプロイ時のデプロイ・プランを保存している場合は、再デプロイでそのデプロイ・プランを再利用できます。デフォルトでは、デプロイ・プランは既存のアプリケーション構成を使用して初期化され、再デプロイに適用されます。前に生成されたOC4Jディスクリプタは、デプロイ・プランの内容に基づいて上書きされます。
アプリケーションを再デプロイした後に、OC4Jの再起動が必要になるのは次のケースのみです。
rmi.xml構成ファイルに変更が行われた場合。
サーバー・レベルのdata-sources.xmlまたはjms.xml構成ファイルに手動による編集が行われた場合。Application Server Control、admin_client.jarまたはOC4J Antタスクによってファイルが変更された場合は、再起動は不要です。
これらのケース以外では、アプリケーションの再デプロイ後にOC4Jを再起動する必要はありません。OC4Jの再起動の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
アプリケーションは再デプロイ中はまったくアクセスできなくなります。受信リクエストは、デプロイが終了してから、更新されたアプリケーションがOC4Jによって再起動されるまで処理されません。
アプリケーションは次の方法でOC4Jインスタンスから削除できます。
Application Server Controlコンソールの「アプリケーション」セクション。
undeploy Antタスク。
このタスクの使用方法は、「アーカイブのアンデプロイ」を参照してください。
admin_client.jarコマンドライン・ユーティリティで提供される-undeployオプション。
このオプションの使用方法は、「アーカイブのアンデプロイ」を参照してください。
OC4JインスタンスからJ2EEアプリケーションを削除すると、次のようになります。
アプリケーションがOC4Jランタイムから削除されます。
Webアプリケーションのすべてのバインドが、WebモジュールがバインドされていたすべてのWebサイトから削除されます。
すべてのアプリケーション・ファイルが、/applicationsディレクトリおよび/application-deploymentsディレクトリから削除されます。
1つ以上の子アプリケーションを持つアプリケーションをアンデプロイすると、子アプリケーションもアンデプロイされます。関連するすべてのアプリケーション（親アプリケーションとそれに依存するアプリケーション）を再デプロイする必要があります。
アプリケーションに対するデプロイメント・ディスクリプタを手動で編集すると、フォーマット・エラーによってアプリケーションおよびその子アプリケーションのアンデプロイが発生します。OC4Jが起動する際、<server.xml>ファイルに記述されたアプリケーションのロードが失敗すると、アプリケーションおよびその子アプリケーションに対するすべてのエントリがファイルから削除されます。フォーマット・エラーを修正した後でOC4Jを再起動しても、アプリケーションがアンデプロイされているためそのアプリケーションをロードできません。
たとえばアプリケーションに対するorion-application.xmlファイルに、<jazn>要素の第1行への余分なスラッシュ（/）とともに次の行が追加されます。
<jazn provider="LDAP" jaas-mode="doAsPrivileged"/>
<jazn-web-app auth-method="COREIDSSO"/>
</jazn>
OC4Jが起動する際、このアプリケーションのロードは失敗し、その<application>要素がserver.xmlファイルから削除されます。orion-application.xmlの<jazn>要素から余分なスラッシュを削除してOC4Jを再起動しても、アプリケーションはデプロイされていないためそのアプリケーションをロードできません。
デプロイメント・ディスクリプタにエラーがあるアプリケーションをOC4Jがロードする前に、そのエラーを修正し、アプリケーションに対するエントリおよびその子アプリケーションに対するエントリを、<server.xml>でリストアする必要があります。アプリケーションを最初からデプロイするか、<server.xml>ファイルを手動で編集することで<application>要素をリストアできます。詳細は、『Oracle Containers for J2EE構成および管理ガイド』のOC4Jへのアプリケーションのデプロイ・オプションに関する項、または付録B「OC4Jで使用される構成ファイル」を参照してください。
