0

OC4J 10.1.2.3 から 10.1.3.1.4 への移行に問題があります。問題は、複数の EJB を持つアプリケーションの場合です (すべて 2.1 で、EJB 3.0 はありません)。Jdeveloper は、デフォルトの ejb-jar.xml (Jdeveloper がスタンドアロン OC4J インスタンスで実行するために必要なもの) を取得し、それを各 EJB JAR モジュールにパッケージ化します。これにより、アプリ サーバーはデプロイ時に各 EJB JAR モジュールにドリルダウンし、同じ ejb-jar.xml ファイルを N 回 (N = EJB モジュールの数) 見つけます。これにより、EJB 参照が重複し、「java:comp/env/ejb/EJBName」などの JNDI ルックアップが中断されます。したがって、EJB1、EJB2、および EJB3 の 3 つの EJB を持つアプリケーションをデプロイすると、アプリケーション サーバーは 3 つではなく 9 つの EJB を登録することになります。ベスト プラクティスの方法が必要ですが、10.1.3.4 と JDeveloper の動作の間で、状況はかなり悲惨です。 ...

補足: Web アプリの JNDI ルックアップ コードが "ejb/EJBName" のみに屈折されている場合、それらは機能します。しかし、これは望ましくありません。

4

2 に答える 2

1

Oracleのドキュメントをチェックして、どちらが当てはまるかを確認する必要があります。Oracle®ContainersforJ2EEEnterpriseJavaBeans開発者ガイドは良いスタートですOracle®ContainersforJ2EEServices Guide、Chapter 2：フォーム「ejb / EJBName」を使用するときにJNDIを使用すると、「ローカル」ルックアップを実行します。完全なフォームを使用する場合は、「JNDIの使用」の章の「グローバルJNDIルックアップの有効化」セクションを確認する必要があります。

于 2008-10-06T12:11:02.610 に答える
0

問題は、展開プロファイルでの複数の参照でした。各 EJB のデプロイメント プロファイルを作成しました。これは、各 EJB が独自の ejb-jar.xml を持つことを意味しました (このファイルには、プロジェクト内のすべての EJB の記述が含まれていました)。したがって、JDeveloper が EJB を作成するたびに、生成した各 EJB にすべての EJB の記述子を配置するため、NxN の量の参照が発生していました。したがって、Nx(N-1) の余分な参照があります。

ここで重要な点は、Oracle Application Server 10.1.2.3.0 以降では、これらの重複参照を気にしていなかったということです。ただし、ご覧のとおり、10.1.3.1.4 はかなり異なるバージョンであり、これは機能しませんでした。

私たちの修正: すべての EJB クラスとそれらが使用する POJO を含む EJB デプロイメント プロファイルを 1 つだけ持つこと。EJB ごとに 1 つの EJB プロファイルが存在する前のことを思い出してください...これにより、Jdeveloper (これはくだらない私見です) が有効な EARを正しく生成できるようになりました。Jdeveloper と Oracle の Application Server のがらくたの組み合わせが原因です。

于 2008-12-08T16:16:14.540 に答える