この章では、EARファイルにパッケージされたJ2EEアプリケーションのOC4Jインスタンスへのデプロイと、OC4JインスタンスからのJ2EEアプリケーションのアンデプロイを説明します。次の項目について説明します。
OC4Jでは、効率のよいユーザーフレンドリなデプロイメント・プロセスが提供されます。 J2EE準拠のEARファイルは、エンタープライズ・アプリケーション・アーカイブ(EAR)ファイルの場所を指定するだけでそのままデプロイでき、変更や再パッケージは不要です。 OC4Jでは、Webアプリケーション・アーカイブ(WAR)やEnterprise JavaBeans(EJB)モジュールなど、アプリケーションを構成するモジュールが自動的にデプロイされます。
次の項では、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.4.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インスタンスにデフォルトでインストールされています。
アプリケーション(OC4J default
アプリケーションを含む)を、Java Platform, Standard Edition(J2SE)Development Kit(JDK)6またはJava Platform 2, Standard Edition(J2SE)Development Kit(JDK)5.0(別名JDK 1.5)上で稼働中のOC4Jにデプロイする場合、そのデプロイをJDK 1.4.2が稼働中のOC4Jインスタンスで再利用することはできません。
JDK 6またはJDK 5.0でコンパイルされたコードはJDK 1.4のVMでは読取りできません。 JDK 1.4.2で稼働中のOC4JがJDK 6またはJDK 5.0でコンパイルされたクラスをロードしようとすると、クラス・ロード例外が次のメッセージとともにスローされます。
Unsupported major.minor version 49.0
この例外は、次のような場合に発生する可能性があります。
JDK 5.0で稼働中のOC4JにEJBモジュールを含むアプリケーションをデプロイし、次に、アプリケーションをアンデプロイせずにJDK 1.4.2で稼働中のOC4Jを再起動した場合。問題は、EJBモジュールに関連して生成されたコードが、サーバーの起動に使用されたのと同じJDKバージョンでコンパイルされ、生成されたコードがサーバーの再起動間にORACLE_HOME
/j2ee/home/application-deployments
ディレクトリのファイル・システム上にキャッシュされることです。
この問題を回避するには、サーバーをシャットダウンし、ORACLE_HOME
/j2ee/home/application-deployments
ディレクトリまたはアプリケーションのサブディレクトリのいずれかの内容を削除し、サーバーをJDK 1.4で再起動します。
JDK 5.0でコンパイルされ、JDK 5.0をターゲットとしたクラスを含むEARファイルを、JDK 1.4.2で稼働中のOC4Jにデプロイした場合。
この問題を回避するには、JDK 1.4.2を使用して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 3.0エンティティのみが含まれる場合を除く)。 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ファイル内にパッケージされたアプリケーションを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は、アクション(インタフェースによる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
構成ファイルを更新します。
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>
要素をリストアできます。 詳細は、「OC4Jへのアプリケーションのデプロイ・オプション」または『Oracle Containers for J2EE構成および管理ガイド』の付録B「OC4Jで使用される構成ファイル」を参照してください。