いくつかの Java ログ記録を掘り下げ、 slf4jについて質問します。.java ファイルで常に同じ方法でログを記録し、ロガー名だけを気にして、適切な .jar および .properties/.xml ファイルを使用してすべてのログ構成を行うと、非常に便利に思えます。
どのプロジェクトでもデフォルトでslf4jを使用する、または使用しない理由は何ですか?
この特定のケースでは、log4j は実際にログを記録し (一部はファイルに、一部は stdout に、一部はデータベースに)、これは Maven プロジェクトです。
経験のある人からの単純な「ええ、それを試してください」または「いいえ、slf4jを使用すると問題Xが発生します」と期待しています。
SLF4J私たちは1.5 年前から API をログに記録しています。それ以前はlog4j直接使用していました。今、私たちは間奏で を使用jboss.loggingしており、logbackすべてのフレームワークの変更に対してコード内のゼロ行を変更する必要がありました。
だから、それのために行く;）
必ず slf4j を使用してください。これは今日の標準的な共通ロギング インターフェイスであり、実際のロギング実装のプラグインに関して最終的に正しく機能します。実装としての Logback を強くお勧めします。これは log4j の後継であり、最初から log4j をやめた同じ人物によって行われましたが、log4j で解決できなかった問題を解決しました。
わかりました、実際にはslf4jを使用せずにlog4jを直接使用することになりました.slf4jはLogBackJDK14LoggerAdapterの代わりに使用し続けたためLog4jLoggerAdapter、依存関係を微調整して動作させるのにうんざりしていました...
問題のプロジェクトは、Maven2 でビルドされた Jenkins プラグインであり、これが問題の原因である可能性があります。「これらの依存関係を .pom に入れるだけ」では、実際には機能しませんでした。
したがって、私自身の質問に答えると、slf4j を使用しない理由は次のとおりです。可動部分が少ない、依存関係が少ない、熟読するマニュアルやドキュメントが少ない、SO/メーリング リストで尋ねる質問が少ない。