新しいプロジェクトでは、log4jの代わりにlogbackを使用する必要がありますか？
新しいプロジェクトでは、ロギングフレームワークとしてlog4jではなくlogbackを使用する必要がありますか？
または別の言葉で：「logbackはlog4jよりも優れていますか（SLF4J-logbackの「機能」を残しますか？）」
ロギングにはSLF4J + Logbackを使用する必要があります。
これは、パラメーター化されたメッセージや（commons-loggingとは対照的に）マップされた診断コンテキスト（MDC、 javadoc 、 documentation ）などのきちんとした機能を提供します。
SLF4Jを使用すると、ロギングバックエンドを非常に洗練された方法で交換できます。
さらに、SLF4J ブリッジをサポートする 使用する実際のSLF4J実装に対する他のロギングフレームワークのサードパーティソフトウェアからのロギングイベントが統合ログに表示される-Java.util.loggingを除く他のロギングフレームワークと同じようにブリッジすることはできません。
Julのブリッジについては、SLF4JBridgeHandlerの javadocs で説明されています。
私はいくつかのプロジェクトでSLF4J + Logbackの組み合わせを使用して非常に良い経験をしており、LOG4Jの開発はかなり行き詰まっています。
SLF4Jには、以下の欠点があります。
- Java <1.5との互換性を維持するための可変引数はサポートしていません
- パラメータ化されたメッセージと例外の両方を同時に使用することはサポートされていません。
- LOG4Jが持つネストされた診断コンテキスト（NDC、 javadoc ）のサポートは含まれていません。
（LogbackとLog4jの両方の）作成者には、変更する理由のリストが http://logback.qos.ch/reasonsToSwitch.html にあります。
ここで私に突き刺さったいくつかを紹介します。
より高速な実装
Log4jに関する以前の作業に基づいて、logback内部は、特定の重要な実行パスで約10倍速く実行するように書き直されました。 logbackコンポーネントはより高速であるだけでなく、メモリフットプリントも小さくなっています。
構成ファイルの自動リロード
Logback-classicは、変更時に構成ファイルを自動的に再ロードできます。スキャンプロセスは、スキャン用に別のスレッドを作成する必要がないため、高速で安全です。この技術的な微妙さにより、アプリケーションサーバー内、より一般的にはJEE環境内でlogbackが適切に機能することが保証されます。
パッケージングデータを含むスタックトレース
Logbackが例外を出力する場合、スタックトレースにはパッケージデータが含まれます。これは、logback-demo Webアプリケーションによって生成されたサンプルスタックトレースです。
14：28：48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction-99は有効な値ではありませんJava.lang.Exception：99は無効です
at ch.qos.logback.demo.prime.PrimeAction.execute（PrimeAction.Java:28）[classes /：na] at org.Apache.struts.action.RequestProcessor.processActionPerform（RequestProcessor.Java:431 ）[struts-1.2.9.jar：1.2.9] at org.Apache.struts.action.RequestProcessor.process（RequestProcessor.Java:236）[struts-1.2.9.jar：1.2.9] org.Apache .struts.action.ActionServlet.doPost（ActionServlet.Java:432）[struts-1.2.9.jar：1.2.9] at javax.servlet.http.HttpServlet.service（HttpServlet.Java:820）[servlet-api- 2.5-6.1.12.jar：6.1.12]
at org.mortbay.jetty.servlet.ServletHolder.handle（ServletHolder.Java:502）[jetty-6.1.12.jar：6.1.12] at ch.qos.logback.demo.UserServletFilter.doFilter（ UserServletFilter.Java:44）[classes /：na] org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.Java:1115）[jetty-6.1.12.jar：6.1.12] org.mortbayに.jetty.servlet.ServletHandler.handle（ServletHandler.Java:361）[jetty-6.1.12.jar：6.1.12] at org.mortbay.jetty.webapp.WebAppContext.handle（WebAppContext.Java:417）[jetty- 6.1.12.jar：6.1.12] at org.mortbay.jetty.handler.ContextHandlerCollection.handle（ContextHandlerCollection.Java:230）[jetty-6.1.12.jar：6.1.12]上記から、アプリケーションがStrutsバージョン1.2.9を使用しており、Jettyバージョン6.1.12でデプロイされていることがわかります。したがって、スタックトレースは、例外に収斂するクラスだけでなく、それらが属するパッケージおよびパッケージバージョンについてもすばやく読者に通知します。顧客がスタックトレースを送信すると、開発者は顧客に、使用しているパッケージのバージョンに関する情報を送信するよう依頼する必要がなくなります。情報はスタックトレースの一部になります。詳細については、「％xThrowable」変換ワードを参照してください。
この機能は、一部のユーザーが誤ってそれをIDEの機能と見なしている場合に非常に役立ちます。
古いログアーカイブの自動削除
TimeBasedRollingPolicyまたはSizeAndTimeBasedFNATPのmaxHistoryプロパティを設定することにより、アーカイブファイルの最大数を制御できます。ローリングポリシーで毎月のロールオーバーが必要で、1年分のログを保持したい場合は、maxHistoryプロパティを12に設定するだけです。12か月より古いアーカイブログファイルは自動的に削除されます。
バイアスがあるかもしれませんが、同じ人が両方のフレームワークを作成し、Log4jよりもLogbackを使用すると言っている場合は、おそらく聞く価値があります。
私はすべてのケースでロギングにslf4jを使用します。これにより、コードタイムではなく、デプロイ時に実際に使用するロギングバックエンドを選択できます。
これは私にとって非常に貴重であることが証明されています。これにより、古いJVMでlog4jを使用したり、1.5以降のJVMでlogbackを使用したり、必要に応じてJava.util.loggingを使用したりできます。
ログバック詳細Java EE対応：
一般に（コードからドキュメントまで）コンテナ（複数のアプリがどのように共存するか、クラスローダーがどのように実装されるかなど）を考慮します。ロガーのコンテキスト、JNDI、JMX構成などが含まれます。
開発者の見込みはほぼ同じで、Logbackはパラメーター化されたロギングを追加します（文字列連結のオーバーヘッドを回避するためにif（logger.isDebugEnabled（））を使用する必要はありません）。
Log4j –ジャイアントプラスのみが古いJVMサポート、小規模（IMO）NDC（ログバックのみMDC）、いくつかの拡張機能です。たとえば、Log4jのconfigureAndWatchの拡張機能を作成しましたが、Logbackにはそのようなものはありません
あなたの決定は、log4jまたはJakarta Commons Loggingのどちらを使用するかを決定した場合と同じになると思います。他のアプリケーションに含まれるライブラリを開発していますか？その場合、ライブラリのユーザーに選択したロギングライブラリの使用を強制することは公平ではないように思われます。
答えが「いいえ」の場合は、何を追加するのがより簡単で、何がより快適であるかを考えます。 logbackのように聞こえるのは、log4jと同じように拡張可能で信頼性があるので、使い慣れている場合は、先に進んでください。
オリジナルのlog4jとlogbackは、同じ人によって設計および実装されました。
いくつかのオープンソースツールがSLF4Jを使用しています。このツールに重大な欠陥はありません。そのため、コードベースにlog4jの拡張機能がたくさんない限り、私はlogbackを進めます。