2 OC4JへのJ2EEアプリケーションのデプロイおよびアンデプロイ

この章では、EARファイルにパッケージされたJ2EEアプリケーションのOC4Jインスタンスへのデプロイと、OC4JインスタンスからのJ2EEアプリケーションのアンデプロイを説明します。次の項目について説明します。

アプリケーション・デプロイ・プロセスの概要
OC4Jアプリケーション・デプロイ・プロセス
アプリケーションの再デプロイの概要
アプリケーションのアンデプロイの概要

アプリケーション・デプロイ・プロセスの概要

OC4Jでは、効率のよいユーザーフレンドリなデプロイメント・プロセスが提供されます。J2EE準拠のEARファイルは、エンタープライズ・アプリケーション・アーカイブ（EAR）ファイルの場所を指定するだけでそのままデプロイでき、変更や再パッケージは不要です。OC4Jでは、Webアプリケーション・アーカイブ（WAR）やEnterprise JavaBeans（EJB）モジュールなど、アプリケーションを構成するモジュールが自動的にデプロイされます。

次の項では、EARをOC4Jにデプロイするときに実行する一般的な手順を示します。

親アプリケーションの指定
WebアプリケーションとWebサイトのバインド
デプロイ・プランの作成または適用
Oracle Application Serverでの動的HTTPサーバーのマウント・ポイントの使用方法
OC4Jアプリケーション・デプロイ・プロセス
デプロイ済アプリケーションへのJDKバージョンの影響
デプロイされたアプリケーション・ディレクトリ構造の例

注意:

読取り専用共有ディレクトリからのEARのデプロイは、エラーが発生することがあるため、お薦めしません。EARファイルをまずローカル・ディレクトリにコピーしてからデプロイしてください。

親アプリケーションの指定

OC4Jにデプロイされるすべてのアプリケーションには、親アプリケーションを指定する必要があります。デフォルトの親は、OC4Jに含まれる、defaultという名前のグローバル・アプリケーションです。

あるアプリケーションを親として指定すると、その子アプリケーションの間でクラスやサービスを共有できます。子アプリケーションは、親アプリケーションのネームスペースを参照して、親がインポートした一連の共有ライブラリを継承します。構成データも親からインポートされますが、子アプリケーションレベルでオーバーライドすることができます。

一旦アプリケーションをデプロイすると、子アプリケーション内のすべてのメソッドは親アプリケーション内のすべてのメソッドを起動できます。この方法により、1つのJAR内のメソッドが、別のJARにデプロイされているEJBモジュールを参照できるようになります。これは、1つのJARファイルにすべてのサービスEJBモジュールをデプロイするときに役立ちます。この場合は、JARファイルのユーザーがサービス・アプリケーションを親として宣言します。

WebアプリケーションとWebサイトのバインド

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 Application Serverでの動的HTTPサーバーのマウント・ポイントの使用方法

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.5.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インスタンスにデフォルトでインストールされています。

デプロイ済アプリケーションへのJDKバージョンの影響

アプリケーション（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

OC4Jアプリケーション・デプロイ・プロセス

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ディスクリプタは、デプロイ・プランの内容に基づいて上書きされます。

RMIまたは手動による再構成後のOC4Jの再起動

アプリケーションを再デプロイした後に、OC4Jの再起動が必要になるのは次のケースのみです。

rmi.xml構成ファイルに変更が行われた場合。
サーバー・レベルのdata-sources.xmlまたはjms.xml構成ファイルに手動による編集が行われた場合。Application Server Control、admin_client.jarまたはOC4J Antタスクによってファイルが変更された場合は、再起動は不要です。

これらのケース以外では、アプリケーションの再デプロイ後にOC4Jを再起動する必要はありません。OC4Jの再起動の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。

アプリケーションは再デプロイ中はまったくアクセスできなくなります。受信リクエストは、デプロイが終了してから、更新されたアプリケーションがOC4Jによって再起動されるまで処理されません。

親アプリケーションの再デプロイの影響

1つ以上の子アプリケーションを持つアプリケーションを再デプロイした後では、各子アプリケーションを再起動する必要があります。再起動することで、親から提供される継承クラスまたは共有ライブラリに子アプリケーションが確実にアクセスできるようになります。

アプリケーションのアンデプロイの概要

アプリケーションは次の方法でOC4Jインスタンスから削除できます。

Application Server Controlの「アプリケーション」セクション
undeploy Antタスク

このタスクの使用方法は、「アーカイブのアンデプロイ」を参照してください。
admin_client.jarコマンドライン・ユーティリティで提供される-undeployオプション

このオプションの使用方法は、「アーカイブのアンデプロイ」を参照してください。

アプリケーションのOC4Jからの削除の結果

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で使用される構成ファイル」を参照してください。