117

他のパッケージではなく、次のパッケージのいずれかを使用するのはなぜですか?

  • Java ロギング
  • コモンズ・ロギング
  • Log4j
  • SLF4j
  • ログバック
4

8 に答える 8

88

APIの出現の時系列順（私が知る限り）：

  • ほとんどの人がLog4jを使用しているため（私の経​​験では）
  • Commons Logging は、オープン ソース プロジェクトで使用されているため (統合ソリューションで使用されているロギング フレームワークと統合できるため)。あなたが API/Framework/OSS であり、Commons Logging を使用する他のパッケージに依存している場合に特に有効です。
  • Commons Logging は、特定のロギング フレームワークに「ロックダウン」したくないためです (代わりに、Commons Logging が代わりに提供するものにロックダウンします)。この点を理由として使用することを決定するのは賢明ではないと思います。
  • 余分な jar を追加したくないため、Java ロギング。
  • SLF4j は、Commons Logging よりも新しく、パラメーター化されたログを提供するためです。
logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}
  • Logback は log4j よりも新しく、SLF4j を直接実装するため、パラメーター化されたロギングをサポートするためです。
  • SLF4j/Logback は、log4j を作成したのと同じ人によって書かれているため、彼はそれを改善しました ( Ken Gによると- ありがとう。彼らの以前のニュース投稿を見ると合っているようです) 。
  • SLF4jはlog4jアダプターも公開しているため、古いコードでlog4jを「切り替える」必要はありません-log4j.propertiesでSLF4jを使用するだけで、その構成です
于 2008-12-10T01:50:10.060 に答える
38

Javaにログインすることは、混乱を招き、一貫性がなく、文書化が不十分であり、特に無計画であることがわかりました。さらに、これらのロギングフレームワークの間には非常に多くの類似性があり、作業が重複し、実際にどのロギング環境にいるのか混乱します。特に、本格的なJava Webアプリケーションスタックで作業している場合は、多くの場合、多数一度に環境をログに記録します。（たとえば、hibernateはlog4jおよびtomcat java.util.loggingを使用する場合があります）。Apache Commonsは、さまざまなロギングフレームワークをブリッジすることを目的としていますが、実際にはさらに複雑になります。あなたがこれを前もって知らなければ、それは全く当惑しています。ログメッセージがコンソールなどに出力されないのはなぜですか？log4jではなくTomcatログを見ているからです。さらに別の複雑さの層を追加すると、アプリケーションサーバーには、特定のWebアプリケーションのローカル構成を認識しないグローバルロギング構成が含まれる場合があります。最後に、これらのロギングフレームワークはすべて非常に複雑です。Javaにログインすることは、私のような開発者を苛立たせ、混乱させてしまう、まとまりのない混乱でした。

初期のバージョンのJavaには、このシナリオにつながる組み込みのロギングフレームワークがありませんでした。

于 2009-03-11T21:26:48.120 に答える
22

以前に言及されなかった1つの重要なポイントがあります：

SLF4J（およびロギングバックエンドとしてのLogbackとLOG4Jの両方）は、いわゆるマップされた診断コンテキスト（MDC、javadocおよびドキュメントを参照）をサポートしています。

これは基本的にスレッドローカルのMap<String、String>であり、ログイベントにコンテキスト情報を追加するために使用できます。MDCの現在の状態は、すべてのイベントに関連付けられています。

これは、ユーザー名やリクエストのURL（Webアプリの場合）などを入力すると非常に便利です。これは、たとえば、フィルターを使用して自動的に実行できます。

于 2009-06-03T04:01:03.423 に答える
17

エラーをログに記録するためのベスト プラクティスは何ですか?という質問への回答も参照してください。、 特に：

  • Commons Logging には、潜在的なクラスロードの問題がいくつかあります。

  • Log4J と SLF4J は、Log4J で実際に見つかった問題から学び、同じ人物によって開発されました。

于 2008-12-10T13:30:10.597 に答える
4

Commons Loggingの概要では、その存在理由を説明しています。つまり、基礎となるロギング フレームワークを制御できない場合に、ライブラリ コードからのロギングです。外部アプリケーションにリンクされるさまざまな Apache プロジェクトにとって非常に重要です。完全に制御できる内部 IT プロジェクトでは、おそらくそれほど重要ではありません。

そうは言っても、私が知っている他の多くの開発者と同様に、私は Commons Logging に投稿しています。その理由は、精神的な荷物を最小限に抑えるためです。プロジェクトや仕事を変えることができ、新しいフレームワークを学ぶ必要はありません (新しい仕事/プロジェクトでも CL を使用している場合、および/または CL に移行するよう説得できる場合)。

また、使用するフレームワークに独自のラッパーを作成することには、ある程度の価値があります。hereで説明されているように、LogWrapper オブジェクトを使用してカスタム文字列化を提供し (重要)、ロギング ステートメントの視覚的な乱雑さを最小限に抑えます (あまり重要ではありません)。

于 2008-12-11T13:48:50.047 に答える
4

私たちの会社のプロジェクトでは LOG4j を使用しており、Stephen が例で示したように非常に使いやすいです。また、LOG4j 用に独自のパターン クラスを作成したので、独自の出力ファイル スキーマを作成できます。ログ ファイルがどのように表示されるかを説明できます。元の log4j クラスを拡張することが可能です。

すべての LOG4j プロパティは log4j.properties ファイルで変更できるため、プロジェクトごとに異なるファイルを使用できます。

Java ロギングは私の好みではありませんが、これは最初から log4j を使用していることが原因かもしれません。

于 2008-12-10T07:15:55.503 に答える
2

通常、デフォルトで Log4J を使用します。

Java 1.4 への依存が気にならない場合は Java Logging を使用しますが、優先的に Log4J を使用します。

Commons Logging を既に使用しているものを拡張する場合は、Commons Logging を使用します。

于 2008-12-10T04:00:46.333 に答える
0

どのロギング フレームワークにも書き込み可能なシン ロギング ファサードを作成することをお勧めします。

于 2008-12-10T04:02:16.440 に答える