すぐに使えるlog4jを多用するアプリケーションがあります。これは多くのサードパーティ API を使用します。これらのサードパーティ API の一部は、ロガーを完全にハッキングし、アペンダーを一掃します。異なる構成で完全に初期化されることがあり、ロギング機能が完全に失われます!!
log4j が簡単にハッキングされる理由を教えてください。これを解決する必要がある場合、log4j の実装を書き直す必要がありますか?
1015 次
3 に答える
2
ロガーを別のクラスローダーに入れてみてください。
于 2012-08-24T18:30:12.430 に答える
0
Log4J は、log4j を構成することが期待されるアプリケーション構成と、log4j の基本を理解せずにライブラリ内で構成する一部のライブラリ開発者とを区別する方法がないため、簡単に「ハッキング」されます。
いくつかのオプションがあると思います：
ライブラリが log4j 構成をいつ壊すかを調べ、後でその構成を上書きするようにしてください。
不正な動作をするライブラリのバグを送信します。オープン ソースの場合は、公式ディストリビューションに含まれているかどうかに関係なく、そのパッチを使用する追加オプションを使用して自分でパッチを送信することもできます。
アプリケーションで Log4J クラスをロードするすべてのものを特別なクラスローダを使用するようにします。たとえば、OSGI を使用するか、独自の LoggerFactory を構築して、log4j LoggerFactory を特別なクラスローダでロードします。ライブラリは明らかにそれを行わないため、独自のLog4Jクラスのセットを取得し、構成に対して何をしても影響しません。
于 2012-08-25T12:39:00.747 に答える
0
正しい場所を参照して、起動時にlog4jを構成するソリューションを探します。それは実行可能なはずです：
- ここで@Markが言及したアプローチを使用するか: How to force log4j load xml config from non src folder?
- または @Jon7 によるもの: How to force log4j load xml config from non src folder?
- または、以下に記載されているアプローチによる: Log4j プロパティ パスの構成に関するベスト プラクティス
1つずつ試してみて、これらのいずれかが問題を解決するかどうかを確認します.
唯一のことは、そのような構成ファイルが複数ある場合、最初のアプローチがあなたのやり方である場合、 javadoc が言うように、 prio を呼び出す必要があるかもしれないresetConfiguration()ということですconfigure()：「既存の構成はクリアもリセットもされません。」
それにprioを呼び出す必要があるかもしれません：
LogManager.resetConfiguration()
したがって、次のいずれかです。
LogManager.resetConfiguration();
DOMConfigurator.configure("/path/to/log4j.xml");
また：
LogManager.resetConfiguration();
PropertyConfigurator.configure("/path/to/log4j.properties");
于 2012-08-25T12:19:09.190 に答える