27 EJBアプリケーションのパッケージ化

この項の内容は次のとおりです。

詳細は、次を参照してください。

『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』
「パッケージ化について」

JPAエンティティ・アプリケーションのパッケージ化

EJB 3.0エンティティを使用するアプリケーションをパッケージ化する場合、次の点を考慮します。

永続性ユニットのパッケージ化

EJB 3.0 JPA永続性ユニットは、persistence.xmlファイル、1つ以上のオプションのorm.xmlファイル、および永続性ユニットに属する管理エンティティ・クラスで構成されます。

永続性ユニットを独自の永続性アーカイブにパッケージ化し、永続性ユニットへのアクセスを必要とする任意のJava EEモジュールにそのアーカイブを含めることができます（「永続性アーカイブの作成」を参照）。または、永続性ユニット・ファイルを様々なJava EEモジュールに直接パッケージ化することも可能です（「Java EEモジュールへの永続性ユニット・ファイルの直接パッケージ化」を参照）。

META-INFディレクトリにpersistence.xmlファイルを含むJARファイルまたはディレクトリは、永続性ユニットのルートと呼ばれます。エンティティを使用するEJB 3.0アプリケーションでは、少なくとも1つの永続性ユニット・ルートを定義する必要があります。

永続性ユニットの有効範囲は、永続性ユニット・ルートを定義する場所によって決まります。

詳細は、次を参照してください。

永続性アーカイブの作成

永続性アーカイブは、例27-1「永続性アーカイブ」に示すように、persistence.xmlファイル、1つ以上のオプションのorm.xmlファイル、および永続性ユニットに属する管理エンティティ・クラスを含む単純なJARファイルです。

例27-1 永続性アーカイブ

employee-persistence.jar
    META-INF/persistence.xml
    META-INF/orm.xml
    com/acme/model/Employee.class
    com/acme/model/Address.class
    ...

永続性アーカイブは、次のいずれかの方法でパッケージ化します。

WAR: WEB-INF/libディレクトリ。永続性ユニットは、このWAR内のクラスからのみアクセスできます。
EAR: ルートまたはアプリケーション・ライブラリ・ディレクトリ。永続性ユニットは、すべてのアプリケーション・コンポーネントからアクセスできます。

永続性アーカイブを使用すると、複数のJava EEモジュールで永続性ユニットを簡単に共有できます。

Java EEモジュールへの永続性ユニット・ファイルの直接パッケージ化

永続性ユニット・ファイルは、次のいずれかのJava EEモジュールにパッケージ化できます。

EJB-JARファイル
WARファイル
- WEB-INF/classesディレクトリ
- WEB-INF/lib（この場合、persistence.xmlファイルはJARにあることが必要）
EAR
- EARのルートにあるJAR内のpersistence.xmlファイル
- EARライブラリ・ディレクトリにあるJAR内のpersistence.xmlファイル

アプリケーション・クライアントJAR

表27-1 OC4JによるMETA-INFおよびWEB-INFのpersistence.xmlの処理方法

WEB-INF/classes/META-INF	WEB-INF	OC4Jがpersistence.xmlを使用する場所
`persistence.xml`	`persistence.xml`	`META-INF`（`WEB-INF`内のファイルを無視）
	`persistence.xml`	`META-INF`
`persistence.xml`		`WEB-INF`

永続性ユニット・ファイルとJava EEモジュールを分離し、複数のJava EEモジュールで永続性ユニットを簡単に共有するには、永続性ユニットを永続性アーカイブにパッケージ化することを検討してください（「永続性アーカイブの作成」を参照）。

マッピング・メタデータのパッケージ化

EJB 3.0 JPAマッピング・メタデータは、アノテーションまたは1つ以上のオプションのorm.xmlファイル（あるいはその両方）を使用して指定できます。orm.xmlファイルは、次のいずれかにパッケージ化できます。

永続性ユニット・ルート（META-INFディレクトリにpersistence.xmlファイルを含むJARファイルまたはディレクトリ）のMETA-INFディレクトリ
persistence.xmlファイルで参照される任意のJARファイルのMETA-INFディレクトリ
persistence.xmlファイルの<persistence-unit>要素の<mapping-file>サブ要素
永続性アーカイブ

詳細は、次を参照してください。

EJB 3.0とEJB 2.1の両方のEnterprise Beanがあるアプリケーションのパッケージ化

EJB 3.0とEJB 2.1の両方のBeanをアプリケーションで組み合せることができます。たとえば、ejb-jar.xmlファイルのない3つのアノテーション付きEJB 3.0エンティティ、ejb-jar.xmlファイルのある2つのEJB 2.1エンティティBean、およびejb-jar.xmlファイル、アノテーションまたはその両方のある3つのEJB 3.0セッションBean（この場合、ejb-jar.xmlはアノテーションをオーバーライドする）を含むアプリケーションが可能です。

EJBアプリケーション間でのクラスの共有

Enterprise Bean間でクラスを共有する場合は、次のいずれかを実行します。

2つのEnterprise Beanが同じクラスを使用する場合は、すべてのクラスとEnterprise Beanを同じJARファイルに含めます。デプロイ後、両方のEnterprise Beanが同じ共通クラスを使用できるようになります。
共有クラスを、アプリケーションのそれぞれのJARファイルに配置します。次のように、EJB JAR manifest.mfファイルのclass-pathにある共有JARファイルを参照します。
```
Class-Path:shared_classes.jar
```
shared_classes.jarの場所は、これを参照するJARファイルがEARファイル内のどこに存在するかによって異なります。この例では、shared_classes.jarファイルは、EJB JARファイルと同じレベルに存在します。
すべてのアプリケーションがこれらのクラスを参照するようにする場合は、共有クラスをJARファイルにアーカイブし、このJARファイルをデフォルト・アプリケーションの共有ライブラリ・ディレクトリに配置します。デフォルトの共有ライブラリはhome/libです。ただし、共有ライブラリ・ディレクトリは、Enterprise Managerを使用してデフォルト・アプリケーションの「一般プロパティ」ページで設定できます。
特定のアプリケーションのみがこれらのクラスを参照するようにする場合は、共有クラスをそれぞれの共有クラス自身のアプリケーションにアーカイブし、アプリケーションのEARファイルをデプロイし、共有クラスを参照するアプリケーションで、その共有クラス・アプリケーションを親として宣言します。OracleASのデフォルトの親は、デフォルト・アプリケーションです。

子アプリケーションは、親アプリケーションの名前空間を認識します。これは、Enterprise Beanなどのサービスを複数のアプリケーションで共有するために使用されます。親アプリケーションの指定方法は、『Oracle Containers for J2EE開発者ガイド』を参照してください。

EJBアプリケーションとWebアプリケーション間でクラスを共有する場合は、参照されるクラスを共有JARファイルに配置する必要があります。

EJBアプリケーション間でクラスを共有する場合、次の問題に注意してください。

実行時のメモリー不足例外の処理

実行時にOC4Jメモリーが一貫して増大し続ける場合は、application.xmlファイルに無効なシンボリック・リンクが指定されている可能性があります。OC4Jは、このapplication.xmlファイルのリンクを使用して、すべてのリソースをロードします。これらのリンクが無効な場合は、Cヒープの増大が続き、OC4Jがメモリー不足となります。すべてのシンボリック・リンクが有効であることを確認し、OC4Jを再起動します。

また、シンボリック・リンクが指し示すディレクトリ内のJARファイル数は最小限にしてください。使用していないJARファイルすべてをこれらのディレクトリから削除します。OC4Jは、クラスとリソースのJARをすべて検索します。したがって、アドレス空間へのマッピングおよびファイル・キャッシュによる時間やメモリーの消費量が増加します。

実行時のクラス・キャスト例外の処理

実行時にClassCastExceptionが発生した場合は、次の状況であることが考えられます。

開発を容易にするために、サーブレットが存在しているWARファイルにEJBインタフェースをコピーしていて、WARファイルを作成する前にインタフェースの削除を忘れていた場合。さらに
orion-web.xmlファイルで、<web-app-class-loader>要素のsearch_local_classes_first属性をオンにしていた場合。

この問題を解決するには、コピーしたクラスをWARファイルから削除するか、またはsearch_local_classes_first属性をオフにします。この属性をオンにすると、クラス・ローダーは、EJB JARファイル内のクラスなどの他のクラスをロードする前に、WARファイル内のクラスをロードします。この属性の詳細は、『Oracle Containers for J2EEサーブレット開発者ガイド』の「サーブレットの開発」の、OC4Jでのシステム・クラスより前のWARファイル・クラスのロードに関する項を参照してください。

他の共有EJBクラスを参照するEJBまたはWebアプリケーションを使用する場合は、参照されるクラスを共有JARファイルに配置する必要があります。状況によっては、WARファイルまたは共有EJBクラスを参照する別のアプリケーションに共有EJBクラスをコピーすると、クラス・ローダーの問題のためにClassCastExceptionが発生する場合があります。正常に終了するためには、参照されるEJBクラスを、そのアプリケーションのWARファイルまたは別のアプリケーションにコピーしないでください。