web-dev-qa-db-ja.com

Log4jはSlf4jのために放棄されていますか？

Log4jにはいくつかの クラスローディングの問題 （とりわけ）があるようで、log4jからslf4jに移動する傾向にあるようです。 （Hibernateは後者を優先して最初の使用を中止しました）

  1. 本当ですか？
  2. Slf4jが解決するlog4jの主な問題は何ですか？
  3. Slf4jが最後の言葉ですか、それともより優れた「次のlog4j」業界標準がありますか？

更新：

  • だからこれ answer by delfuegoは私を混乱させます、あなたはそれを受け入れる/反対することができますか？：

Log4j（およびApache Commons Loggingライブラリ）の主な問題に遭遇したようです。つまり、適切なクラスローダーを使用していると、それらを発見して操作するのが途方もなく困難です。ここには例を挙げた非常に緻密な説明があります。 持ち帰りメッセージは、新しいロギングフレームワークSLF4Jの主な原動力の1つは、これらの問題を完全に排除することでした。 あなたはそれを交換して、あなたの人生がもっと楽になったかどうかを見たいかもしれません。

javalog4jslf4j
49
ruchirhhi

Slf4jは確かに単なるロギングファサードです。ただし、Log4jは、まったく同じ作者による Logback に続くことを意図しています。

Update：Slf4jの別の利点について知りたい場合は、次の（醜い）構成が不要になるため、 toString()が不必要に呼び出されました：

if (logger.isDebugEnabled()) {
    logger.debug("Message: " + bigObject + ", " + anotherBigObject);
}

代わりに、パラメータ化されたメッセージを利用できます。

logger.debug("Message: {}, {}", bigObject, anotherBigObject);

も参照してください ログを記録する（しない）の最速の方法は何ですか？

47
BalusC

Slf4JはLog4jの代替ではなく、ロギング用のファサードを提供するため、独自のロギングフレームワークをプラグインできます。主にライブラリに役立ちます。 slf4j.orgから：

Javaまたは（SLF4J）のシンプルなロギングファサードは、Java.util.logging、log4j、logbackなどのさまざまなロギングフレームワークのシンプルなファサードまたは抽象化として機能し、エンドユーザーがデプロイメント時に必要なロギングフレームワーク。

あなたの質問に答える：Slf4jは現在フレームワークで採用されていますが、プロジェクトでは、Log4J（またはその他）を使い続けることができます

18
EJB

まず、重要なポイント：Slf4jはフロントエンドのロギング（API）であり、ほとんどの主要なロギングシステム（log4jまたはJava.util.loggingなど）の下で使用できます。したがって、sfl4jを commons-logging と比較することをお勧めします。

Log4jの状態については、 The state of Java logging （1年前）から引用しています。

私が気づかなかったことの1つは、log4j開発が本質的に死んでいるということです。現在バージョン1.2であり、バージョン1.3の計画はlog4j 2.0の開発を支持して中止されました。しかし、2.0が活発に開発されているようには見えません。 log4jプロジェクトの最初の創設者であるCekiGülcüがslf4jに移行したことは注目に値します（以下を参照）。

7
Kartoch

slf4jページ を見ると、replaceのようには見えませんlog4j-同じものを使用できるようにするだけですアプリケーション全体の基盤となるロギングフレームワーク（log4jなど）。ライブラリが自動的にフックできるようにします。

Apache Commons Logging の代わりにlog4jよりも似ています。

6
Jon Skeet

私の意見では、SLF4Jには、提供するブリッジを通じて使用するすべてのライブラリーのロギングを統合できるという大きな利点があります。他のロギングフレームワークはどちらもこれを許可していません。これにより、プロジェクトはSLF4Jにスムーズに移行し、依存関係が行ったロギングフレームワークの選択を無視できます。

3
Thomas Lötzer

Slf4jは実際のロギングファサードではありません。 Slf4jは、その実装者の多くの機能をサポートしていません。簡単に言うと、以下でlog4jの例について触れます。

  • Slf4jはユーザーが選択した構成ファイルを指定できませんが、ユーザーは多くのJavaルートのいずれかでデフォルト（log4j.propertiesまたはlog4j.xml）を使用するように強制します（各Jarには1つのルートとJVMルートがあり、クラスまたはビン）。2つのJARファイルに含まれている場合、どちらを安全に使用するかを制御することは困難です。
  • Slf4jは、「致命的」など、すべてのLog4jレベルをサポートできるわけではありません。大きなコードをLog4jからSlf4jに切り替える場合、膨大なコード変更の労力が必要です（たとえば、レベルを再配置する方法を決定する）。
  • 2つの主要なJARファイル（log4j-over-slf4j.jarまたはslf4j-log4j12.jar）を選択する必要があります。クラスパスが両方の場合、機能しません。ランダムに1つを選択すると、予期しない機能が失われます（たとえば、log4j-over-slf4j.jarは、同じクラスの複数のログファイルをサポートしていません。たとえば、1つはイベントログ用で、もう1つは生データログ用です）。
3
Steven S Wang