2

なぜcontext.xmlファイルを使用してリソース（私の場合はデータベース接続プール）を宣言するのか理解できません。うまくいけば、context.xmlの使用に反対する次の議論で私の事実をまっすぐに理解できます

  1. 私の知る限り、/ META-INF / context.xmlで宣言されたリソースはコンテキスト内でのみ使用可能であるため、リソースを共有するためにそうする理由はありません。

  2. この方法で接続プールリソースを宣言すると、コンテナのクラスローダーへの依存関係が作成されるため、たとえば、データベースドライバを変更したい場合は、コンテキストだけでなく、コンテナを再起動する必要があります。

  3. また、JNDIのようなコンテナに依存するため、スタンドアロンテストが難しくなります。

  4. 最後に、ビルド時のフープを飛び越えて、たとえばテストリソースと本番リソースの間でリソースを切り替える必要があります。

これらの問題はどれも克服できないものではありませんが、接続プールを作成してコンテキストスコープにフックする方がはるかに簡単なようです。

context.xmlファイルが正しい答えはどのような状況であるか知りたいですか？

4

2 に答える 2

1

私が見た唯一の正当な理由は、Tomcatが基本的なユーザー認証呼び出しのようなものに接続プールを使用できるようにしたい場合、JDBC UserAuthコンテキストを使用するように設定されている場合は、Tomcatに接続プールを持たせたい場合があります。

于 2009-06-10T18:49:21.477 に答える
1

を使用するもう1つの理由は、サーブレットのinitパラメータcontext.xmlをオーバーライドすることです。このパラメータを使用して、Springなどで管理されているDBCPなど、さまざまな設定を行うことができます。

これは、システムプロパティや環境変数よりも優先される可能性があります。これは、同じWARの複数のコピーを、WARを変更せずに単一のコンテナーにデプロイでき、それらの構成が重複しないためです。

ちなみに、context.xmlはWARの外に住むことができます（それに関するTomcatのドキュメントまたは以下のスニペットを参照してください）：

個々のコンテキスト要素は明示的に定義できます。

  • アプリケーションファイル内の/META-INF/context.xmlにある個々のファイル。オプションで（ホストのcopyXML属性に基づいて）これを$ CATALINA_BASE / conf / [enginename] / [hostname] /にコピーし、アプリケーションのベースファイル名と「.xml」拡張子に名前を変更できます。
  • $ CATALINA_BASE / conf / [enginename] / [hostname] /ディレクトリ内の個々のファイル（拡張子は「.xml」）。コンテキストパスとバージョンは、ファイルのベース名（ファイル名から.xml拡張子を差し引いたもの）から取得されます。このファイルは、WebアプリケーションのMETA-INFディレクトリにパッケージ化されているcontext.xmlファイルよりも常に優先されます。
  • メインのconf/server.xmlのHost要素内。

複数のWebアプリケーションに適用されるデフォルトのコンテキスト要素を定義できます。個々のWebアプリケーションの構成は、これらのデフォルトの1つで構成されたものをすべてオーバーライドします。デフォルトのコンテキストで定義されているネストされた要素（要素など）は、デフォルトが適用されるコンテキストごとに1回作成されます。それらはコンテキスト要素間で共有されません。

  • $ CATALINA_BASE / conf / context.xmlファイル：Context要素情報はすべてのWebアプリケーションによってロードされます。
  • $ CATALINA_BASE / conf / [enginename] / [hostname] /context.xml.defaultファイル：Context要素情報は、そのホストのすべてのWebアプリケーションによってロードされます。
于 2015-05-31T17:33:04.870 に答える