7

私のサーブレットアプリケーションには、いくつかのライブラリ.jarが含まれており、そのうちのいくつかには、log4j.xmlまたはlog4j.propertiesファイルが埋め込まれています。log4jが最初にlog4j.xmlを見つけるようにしたいです！サーブレット内のさまざまなクラスパス要素の優先順位の仕様を検索しようとしました（たとえば、WEB-INF/クラスは常にWEB-INF/ libの前にありますか？）、またはサーブレットのクラスローダーを構成または微調整して、指定されたリソースディレクトリは、クラスパスの早い段階で表示されます。これまで、空白を描画しました。サーブレットの.warファイルがクラスローダーを介して正しいlog4j.xmlをロードすることを確認するための提案はありますか？

4

6 に答える 6

15

Tomcat 8.5

同上Tomcat8.0。

ドキュメントを参照してください：クラスローダーHOW-TO。

Tomcat 8.0

答えは簡単で、TomcatのドキュメントページであるClassLoaderHOW-TOから引用しています。特に、/WEB-INF/ディレクトリ/フォルダの使用に注意してください。

したがって、Webアプリケーションの観点から、クラスまたはリソースのロードは、次のリポジトリーをこの順序で調べます。

  • JVMのブートストラップクラス
  • /WEB-INF/classesあなたのウェブアプリケーションの
  • /WEB-INF/lib/*.jarあなたのウェブアプリケーションの
  • システムクラスローダークラス（上記）
  • 一般的なクラスローダークラス（上記）

Webアプリケーションクラスローダーがで構成されている<Loader delegate="true"/>場合、順序は次のようになります。

  • JVMのブートストラップクラス
  • システムクラスローダークラス（上記）
  • 一般的なクラスローダークラス（上記）
  • /WEB-INF/classesあなたのウェブアプリケーションの
  • /WEB-INF/lib/*.jarあなたのウェブアプリケーションの

Tomcat 6

Tomcat 6ページ、クラスローダーHOW-TOから抜粋。

したがって、Webアプリケーションの観点から、クラスまたはリソースのロードは、次のリポジトリーをこの順序で調べます。

  • JVMのブートストラップクラス
  • システムクラスローダークラス（上記）
  • /WEB-INF/classesあなたのウェブアプリケーションの
  • /WEB-INF/lib/*.jarあなたのウェブアプリケーションの
  • $CATALINA_HOME/lib
  • $CATALINA_HOME/lib/*.jar
于 2008-11-05T15:49:14.457 に答える
5

私が理解している限り、クラスパスからのリソースの選択は非決定的です（アプリ開発者の観点から）。同じファイルが一貫してロードされている場合でも、動作が変わる可能性があります。1.現在のコンテナーのバージョンをアップグレードする場合。2.コンテナを切り替える場合。

最も簡単な解決策は、ライブラリjarから埋め込まれたlog4j構成ファイルを削除することです。ここで見られる問題につながるため、log4j構成を埋め込むことはほとんど決して良い考えではありません...

それらはサードパーティのjarファイルですか、それともあなたが開発したjarファイルですか？

于 2008-11-05T11:02:10.120 に答える
3

Log4jConfigListenerweb.xmlファイルのSpringです。

log4j構成ファイルの場所をコンテキストパラメーターとして指定できます。つまり、/ WEB-INF/log4j.xmlとして設定できます。

これはあなたにとっての選択肢でしょうか？Springを使用していない場合は、Log4jの場所をプログラムで設定できることを知っています。これも機能する可能性があります。

于 2008-11-05T11:23:14.040 に答える
1

私の経験では、通常、WEB-INF/classes は WEB-INF/lib の jar よりも優先されますが、これは使用するサーブレット コンテナーにも依存します (たとえば、JRun の動作を理解することはできませんでした)。使用しているコンテナを教えていただけると大変助かります。

また、問題のある log4j 構成が WEB-INF/lib の jar にあることは確かですか? 通常、サーブレット コンテナーの状況でクラスパスの問題に遭遇した場合、それは Web アプリの外部に存在するライブラリが原因です。

サーブレットの仕様では、コンテナのクラスローダー (SRV.9.7.2) に委譲する前に Web アプリのクラスローダーが独自のクラスをロードすることを推奨していますが、これは Java 仕様に反しているため、すべてのベンダーがデフォルトでこれを行うわけではありません (実際、Tomcat は唯一の私が使用したコンテナはデフォルトでこれを行います）。そうは言っても、コンテナーの Web アプリ クラスローディング動作を構成することは常に可能です。使用しているコンテナを教えていただければ、お手伝いできるかもしれません (具体的には、WebLogic、WebSphere、Glassfish、および JRun でこれを成功させたことがあります)。

于 2008-11-05T12:30:28.320 に答える
1

Tomcat がクラスパスを設定しているため、クラスパスを制御できない場合、少なくともシステム プロパティを設定できますlog4j.configurationか? そのプロパティが指す場所は、クラスパスの外に設定できると思います。

そうでない場合は、醜い方法ではありますが、アプリケーション コードでコンフィギュレーターの 1 つを自分で明示的に実行するという別の方法があります。

于 2008-11-05T14:57:46.447 に答える
-1

CLASSPATHにlog4j.propertiesが必要です。最適な場所はWEB-INF/classesの下です。

また、log4j.jarのバージョンを使用していることを確認する必要があります。したがって、Tomcatフォルダからのものを使用していないことを確認するためにWEB-INF / libに入れてください。これは、奇妙なクラスローディングの問題を引き起こす可能性があるためです。

于 2008-11-05T10:55:07.717 に答える