私のアプリケーションは EAR ファイルとしてデプロイされます。
このアプリケーションでは、従来、インストール後に構成を変更する必要がありました。
Oracle 10G OAS では、EAR がディレクトリに展開され、構成ファイルに簡単にアクセスできるため、これは簡単でした。
11G では、EAR は展開されないため、EAR の展開、変更、および再結合に関する追加のドキュメントが作成されます。
これは、おそらく J2EE を介した標準的なソリューションでは比較的一般的な問題であるに違いないと思われます。
1) デプロイ前に EAR ファイルを変更するユーティリティを提供する。2) すべての構成設定を別の場所に保管します。3) すべての構成設定をデータベースに保存します。コンテナーを介してデータベースにアクセスし、JNDI を介して公開された接続を提供します。
しかし、確立されたベストプラクティスはありますか?
それが欠けている場合、どのアプローチが効果的でしたか?
ありがとうカーティス
私はクライアントの 1 人と、このテーマに関していくつかの重要な作業を行いました。一言で言えば（私はあなたを助けると信じています）：
構成ファイルを使用する場合、EAR 内に構成ファイルを配置すると (展開/再パッケージ化によって)、EAR ファイルが異なる環境間 (たとえば、QA 環境と本番環境) で移植できないという欠点があります。時間の経過とともに、これによりオーバーヘッドが増加し、環境間で混乱が生じる可能性が常にあります。このようなアプローチは、環境に依存しない構成アイテムに対してのみ実行可能です。つまり、すべての SDLC 環境 (QA、テストなど) で同じままです。
または、これらのファイルを別のディレクトリに配置し、そのディレクトリをサーバーのクラスパスに追加することもできます。これは、アプリケーション サーバーごとに異なる方法で行われます。WebSphere では、これは「共有ライブラリ」機能を使用して行われます。
長期的には、私たちにとってより効果的なアプローチは、そのようなタスクに使用するために実際に指定された J2EE テクノロジを使用することresource environment entriesですjava:comp/env。
私はリソース環境エントリのアプローチを他の何よりも好むでしょう...ほとんどすべての可能な解決策を試した後。
私の知る限り、これは依然として問題点の 1 つであり、あなたの分析はほぼ正しいものです。
これは、Java.netフォーラムで以前に書いた同様の質問に対するより詳細な回答ですが、Glassfishを使用していました。
この問題に関して、仕様の根本的な変更については聞いたことがありませんが、役立つ Oracle AS 固有のものがあるかもしれません。