Javaのロギングはどうなっていますか？[閉まっている]

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

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

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

• ほとんどの人が（私の経験では）Log4jを使用しているため
• Commons Loggingは、オープンソースプロジェクトで使用されているため（統合ソリューションで使用されているロギングフレームワークと統合できるため）。API /フレームワーク/ OSSで、Commons Loggingを使用する他のパッケージに依存している場合に特に有効です。
• Commons Loggingは、特定のロギングフレームワークに「ロックダウン」したくないため（代わりに、Commons Loggingが提供するものにロックダウンしたいため）、この点を理由として使用することを決定するのは賢明ではないと思います。
• 追加のjarを追加したくないため、Javaロギング。
• Commons Loggingよりも新しく、パラメーター化されたロギングを提供するSLF4j：

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を使用し、その設定を行うだけです。

Javaでのログインは、混乱し、一貫性がなく、文書化が不十分で、特に無計画であることがわかりました。さらに、これらのロギングフレームワークには非常に多くの類似点があり、結果として作業が重複し、実際にどのロギング環境にいるかについて混乱が生じます。特に、深刻なJava Webアプリケーションスタックで作業している場合は、複数一度にロギング環境。（たとえば、hibernateはlog4jとtomcat java.util.loggingを使用する場合があります）。Apacheコモンズは、異なるロギングフレームワークを橋渡しすることを目的としていますが、実際にはさらに複雑になります。これが事前にわからない場合は、まったく困惑します。ログメッセージがコンソールなどに出力されないのはなぜですか？ああ、私はlog4jではなくTomcatのログを見ているからです。さらに複雑なレイヤーを追加すると、アプリケーションサーバーには、特定のWebアプリケーションのローカル構成を認識できないグローバルロギング構成が含まれる場合があります。最後に、これらのロギングフレームワークはすべて複雑すぎます。Javaでのロギングはまとまりのない混乱であり、私のような開発者は苛立たせて混乱しています。

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

これまでに触れられていない重要な点が1つあります。

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

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

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

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

• Commons Loggingには、潜在的なクラスローディングの問題があります。

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

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

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

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

コモンズロギングの概要は、その存在理由を与える：あなたは基本的なロギングフレームワークを制御することはできませんライブラリコードからログを、。外部アプリケーションにリンクされるさまざまなApacheプロジェクトにとって非常に重要です。完全に制御できる内部ITプロジェクトではおそらくそれほど重要ではありません。

そうは言っても、私が知っている他の開発者の多くがそうであるように、私はCommons Loggingに書き込みます。その理由は、精神的な手荷物を最小限に抑えるためです。プロジェクトまたはジョブを変更でき、新しいフレームワークを学習する必要はありません（新しいジョブ/プロジェクトもCLを使用している、および/またはそれらに移動するように説得できる）。

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

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

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

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

ロギングフレームワークのいずれかに書き込むことができるシンロギングファサードを作成することをお勧めします。その時点で、バッキングエンジンの選択はほとんど問題になります。