49

log4j にはいくつかのクラス ローディングの問題があるようで、log4j から slf4j に移行する傾向にあるようです。(Hibernate は後者を優先して最初の使用を停止しました)

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

アップデート：

log4j (および Apache Commons Logging ライブラリ) の主要な問題に遭遇したようです。つまり、使用されている適切なクラスローダーを発見して対話するのに途方もなく苦労しているということです。ここには、例を含む非常に詳細な説明があります。持ち帰りのメッセージは、新しいロギング フレームワーク SLF4J の主要な原動力の 1 つは、これらの問題を完全に排除することであったということです。交換して、生活が楽になるかどうかを確認してください。

4

6 に答える 6

47

Slf4j は実際には単なるロギング ファサードです。ただし、Log4j は、まったく同じ作成者によるLogbackに引き継がれることを意図しています。

更新: Slf4j の別の利点について知りたい場合は、不必要に呼び出されることを避けるために、次の (醜い) コンストラクトがtoString()不要になったという事実です。

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

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

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

ロギングの (ない) 最速の方法は何ですか?も参照してください。

于 2010-01-14T12:16:20.543 に答える
18

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

Simple Logging Facade for Java または (SLF4J) は、さまざまなロギング フレームワーク (java.util.logging、log4j、logback など) の単純なファサードまたは抽象化として機能し、エンド ユーザーがデプロイ時に目的のロギング フレームワークをプラグインできるようにします。

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

于 2010-01-14T12:08:26.973 に答える
7

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

Log4jの様子についてはJavaロギングの様子（一年前）より引用

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

于 2010-01-14T12:09:24.553 に答える
6

slf4j ページを見ると、 log4j を置き換えるようには見えません。アプリケーション全体で同じ基礎となるロギング フレームワーク (log4j など) を使用できるようになり、ライブラリがそれに自動的にフックできるようになります。

log4j というよりは、 Apache Commons Loggingの代わりのように見えます。

于 2010-01-14T12:07:13.537 に答える
3

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

  • Slf4j はユーザーが選択した構成ファイルを指定できませんが、ユーザーは非常に多くの Java ルートの 1 つでデフォルト (log4j.properties または log4j.xml) を使用する必要があります (各 Jar には 1 つのルートと JVM ルートおよびクラスまたはビンがあります)。2 つの JAR ファイルがある場合、どちらを安全に使用するかを制御するのは困難です。
  • Slf4j は、'fatal' などのすべての Log4j レベルをサポートできません。大きなコードを Log4j から Slf4j に切り替える場合、膨大なコード変更作業が必要になります (レベルの再配置方法の決定など)。
  • 2 つの主要な Jar ファイル (log4j-over-slf4j.jar または slf4j-log4j12.jar) を選択する必要があります。クラスパスが両方の場合、機能しません。ランダムに 1 つを選択すると、予期しない機能が失われます (たとえば、log4j-over-slf4j.jar は、同じクラスの複数のログ ファイルをサポートしていません。たとえば、1 つはイベント ログ用で、もう 1 つは生データ ログ用です)。
于 2012-07-08T16:20:05.507 に答える
3

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

于 2010-01-14T12:08:10.220 に答える