私は現在、中規模から大規模のJavaコードベースでロギングメカニズムをアップグレードすることを検討しています。メッセージは現在、Debugクラスの静的メソッドを使用してログに記録されています。これからSLF4Jやcommons-loggingなどに切り替えることをお勧めします。ログフレームワークを追加レイヤーにラッピングする価値はありますか？
アプリケーションアーキテクトはSLF4Jへの依存性をカプセル化することを望んでいます（おそらく前述のDebugクラスにそれをラップすることによって）。これにより、今後のロギングの実装を簡単に変更できます。
これは、SLF4Jがすでに具体的なロギングの実装を抽象化しているため、これは私にとっては残酷なようです。
SLF4Jのようなサードパーティのログの抽象化をラベリングする価値がありますか自家製抽象化？
私はあなたに完全に同意します：ラッパーのラッパーのラッパーが外れています。 SLF4Jがどのように他のロギング・システムを簡単にラップすることができるのか、アーキテクトは認識していないと思うので、「実装の変更」は別のラップ・レイヤーがなければ完全に実現可能です。
確かに。 SLF4Jから完全に消滅するか、まったく新しい方法のロギングを発明する人は、誰もが今やっているやり方とはまったく違う2つの理由しか予期できません。両方とも同じようには思えない:) – harto
+1 @ hartoのコメントはとても完璧なサウンドビーだから！ - ） –
私は建築家が実際にslf4jを試していなかったと思いますが、それが実装ではなくAPIであることに気づいていませんでした。 –
今後、ロギングフレームワークを切り替えることを検討している場合は、ロガーを切り替える場所に余分なレイヤーを追加することをお勧めします。そうでなければ、それらがあなたが必要とするであろうすべてのものを提供しているなら（もちろんクリスタルボールを使って）、おそらくそのフレームワークに依存しても大丈夫です。
現在の設定で柔軟に変更できる場合は、ラッパーは必要ありません。
Architecture Astronautには、すでにslf4jがlog4jなどの他のロギング実装用のラッパーとして機能していることを説明してください。だから将来的に別のロガーを使用する必要があり、slf4j用のアダプタがない場合は、必要なときに書き込むことができますが、アダプタを使用するだけで、他のロガーフレームをラップする全体のログフレームワークを作成するのではなくなりますフレームワークをロギングし、そのためのフレームワークを設計し、独自のアダプタを作成する必要があります。
私はそれをラップすることをお勧めしますが、上記の理由ではありません。懸念事項が別のフレームワークのためにスワップアウトできる場合は、java.util.loggingまたはSLF（java.util.loggingはラッパーとして使用するのは簡単ではありませんが、かなり実行可能です）を使用してスワップしてください。 （まだ別の）ラッパーを使用する理由は、適切なロギング方法をコード化することです。一般に、アプリケーションでは、すべてのシステムエラーに例外が付いているなどのサブセットが必要です。また、標準ログレベルをいつ使用するかについての具体的なガイダンスがあります。これらの決定は、大規模なコードベースでより一貫したロギングの決定を作成するいくつかの方法でカプセル化することができます。
しかしながら、動機づけが実装を取り替えることを可能にするだけであれば、ホイールを再発明しないでください。 SLFは仕事にぴったりです。ただ使ってください。
これには例外が1つあります。あなたのコードが無意識のうちに多くのアプリケーションサーバーにデプロイされることになっている場合、ロギングの選択が、フレームワークが使用しているものの古いバージョンまたは新しいバージョンと競合する危険性がないことを確認する必要があります。
ログの適切な方法についての良い点。ロギングが一貫性のある方法で確実に行われるようにすることが重要です。配備の考慮事項に関して、コアライブラリは、Webアプリケーションの一部としてだけでなく、デスクトップにも配備されています。しかし、私たちは一般的にTomcat 6しか使用していないので、それは心配だとは思わない。 – harto
独自のログラッパーを追加すると、ロギングバックエンドの呼び出し場所機能が破壊される可能性があります。それだけでなく、十分に使用されているサードパーティのモジュールがほとんど（相対的な方法で）バグフリーである一方で、あなたがサポートしなければならないもう一つのモジュール（デバッグ、バグ修正）です。 – Huxi
ほとんどの場合、相対的な方法で？ねえ、ユーザーを恐れるな！ :-) – Ceki
すべてのラッパーの問題は、あなたが実際にラップだろうとあなたが提供するよどの機能をどのように決定です：
現在のデバッグクラスはわかりませんが、かなり基本的なものです。
おそらく
あなたのDebugクラスが、これはあなたのため実際には非常にいいです:)
それはあなたがおそらくグローバル検索& destrを実行することによって、SLF4Jに切り替えることが可能であることを意味しかなり基本的ある場合。 .. err ...置き換えてください。
、バックアップを作成しますけれども...;）
もShould new projects use logback instead of log4j?、What’s Up with Logging in Java?、Which log4j facade to choose?、Find a way in the java logging frameworks scene.とDo you find java.util.logging sufficient?参照してください。 （Spoiler：java.util.loggingは使用しないでください）
ラッパー（つまりSLF4J）をラップしたいという意欲の背後にある動機は、SLF4Jからアプリケーションを分離することだと思います。明らかに、アプリケーション内からSLF4J APIを呼び出すと、SLF4Jに依存するようになります。しかし、後述するように、分離原理を繰り返し適用することも同様に正当です。それはリチャード・ドーキンスの質問を私に思い起こさせます：神が宇宙を創造したら、誰が神を創造したのですか？
実際、SLF4Jをラップするラッパーに分離原則を適用することもできます。 SLF4JラッパーがSLF4Jに何らかの形で劣っていた場合、分離の原因になることがあります。可能であれば、ラッパーが元のラッパーと同じかそれを上回ることはむしろまれです。 SWTは注目に値する反例として引用することができます。しかし、SWTはかなりのコストをかけて大規模なプロジェクトです。さらに、SLF4JラッパーはSLF4Jに依存しています。同じ汎用APIを持つことになります。将来、新たに大きく異なるロギングAPIが登場する場合、ラッパーを使用するコードは、SLF4Jを直接使用するコードとして新しいAPIに移行することも同様に困難になります。したがって、ラッパーはコードを将来的に証明することはできませんが、追加の間接参照を追加することでコードを重くすることができます。
要するに、何もしなくても、ラッパーの付加価値がゼロに近いことが保証されているため、SLF4Jのラッピングに時間を費やすべきではありません。
トピックはまた、SLF4J FAQ entryでブロッキングされています。
建築家はslf4jが何であるか理解していません。 –