78

新しいプロジェクトでは、ログ フレームワークとして log4j の代わりに logback を使用する必要がありますか?

または、言い換えれば、「logback は log4j よりも優れていますか (logback の SLF4J の「機能」は別として)?」

4

7 に答える 7

83

ロギングには SLF4J+Logback を使用する必要があります。

パラメータ化されたメッセージや (commons-logging とは対照的に) マップされた診断コンテキスト (MDC、javadoc、ドキュメント) などの優れた機能を提供します。

SLF4J を使用すると、ロギング バックエンドが非常に洗練された方法で交換可能になります。

さらに、SLF4Jは、使用する実際の SLF4J 実装への他のロギング フレームワークのブリッジをサポートしているため、サード パーティ ソフトウェアからのロギング イベントが統合ログに表示されます。他のロギング フレームワークと同じ方法です。

JUL のブリッジングについては、 SLF4JBridgeHandlerの javadocで説明されています。

私はいくつかのプロジェクトで SLF4J+Logback の組み合わせを使用して非常に良い経験をしてきましたが、LOG4J の開発はかなり停滞しています。

SLF4J には、次の欠点が残っています。

  • Java < 1.5 との互換性を維持するための varargs はサポートされていません
  • パラメータ化されたメッセージと例外の両方を同時に使用することはサポートされていません。
  • LOG4J が持つネストされた診断コンテキスト (NDC、 javadoc )のサポートは含まれていません。
于 2009-05-31T22:10:56.907 に答える
22

(Logback と Log4j の両方の) 作成者は、http://logback.qos.ch/reasonsToSwitch.htmlで変更する理由のリストを持っています。

ここに私に突き出たいくつかがあります。

  • より迅速な実装

    log4j に関する以前の作業に基づいて、特定の重要な実行パスで約 10 倍高速に実行するように logback 内部が書き直されました。logback コンポーネントは高速であるだけでなく、メモリ フットプリントも小さくなっています。

  • 構成ファイルの自動リロード

    Logback-classic は、変更時に構成ファイルを自動的にリロードできます。スキャン プロセスは、スキャン用に別のスレッドを作成する必要がないため、高速かつ安全です。この技術的な繊細さにより、logback はアプリケーション サーバー内で、より一般的には JEE 環境内で適切に機能します。

  • パッケージ データを含むスタック トレース

    logback が例外を出力すると、スタック トレースにパッケージ データが含まれます。以下は、logback-demo Web アプリケーションによって生成されたサンプル スタック トレースです。

    14:28:48.835 [btpool0-7] INFO cqldemo.prime.PrimeAction - 99 は有効な値ではありません java.lang.Exception: 99 は
    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] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar] :1.2.9] javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [サーブレット-api-2.5-6.1.12.jar:6.1.12]
    org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12] で ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) ) [classes/:na] at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12] at 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] 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 を使用すると言っている場合は、おそらく耳を傾ける価値があります。

于 2011-05-18T12:27:21.463 に答える
10

すべての場合で、ログに slf4j を使用します。これにより、コード時ではなくデプロイ時に、使用する実際のロギング バックエンドを選択できます。

これは私にとって非常に価値があることが証明されています。これにより、古い JVM で log4j を使用したり、1.5 以降の JVM で logback を使用したり、必要に応じて java.util.logging を使用したりできます。

于 2009-01-20T12:47:08.900 に答える
2

より多くの Java EE を認識したログバック:
一般的に (コードからドキュメントまで) コンテナーを念頭に置いています。複数のアプリがどのように共存するか、クラス ローダーがどのように実装されるかなどです。ロガー、JNDI、JMX 構成などのコンテキストが含まれます。

開発者の見通しからほぼ同じ、Logback はパラメータ化されたロギングを追加します (文字列連結のオーバーヘッドを避けるために if(logger.isDebugEnabled()) を使用する必要はありません)

Log4j – 古い JVM サポート、小さい (IMO) NDC (Logback のみの MDC)、いくつかの拡張機能のみが巨大なプラスです。たとえば、Log4j の configureAndWatch の拡張機能を書きましたが、Logback にはそのようなものはありません

于 2010-04-22T17:02:32.517 に答える
1

log4jとJakartaCommonsLoggingのどちらを使用するかを決定する場合と同じ決定を下す必要があると思います。他のアプリケーションに含まれるライブラリを開発していますか？もしそうなら、あなたのライブラリのユーザーにあなたの選択したロギングライブラリも使用するように強制することは公平ではないようです。

答えが「いいえ」の場合は、追加が簡単なものと、より快適なものを使用します。logbackは、log4jと同じように拡張可能で信頼性が高いように思われるので、使い慣れている場合は、先に進んでください。

于 2008-10-07T15:50:10.000 に答える
1

オリジナルの log4j と logback は、同じ人物によって設計および実装されました。

いくつかのオープン ソース ツールが SLF4J を使用しています。このツールに重大な欠陥は見当たりません。したがって、コードベースに log4j の拡張機能が多数含まれていない限り、私は logback を使用します。

于 2008-10-07T15:08:32.377 に答える
-3

私は SLF4J に詳しくなく、logback について簡単に調べただけですが、2 つのことが思い浮かびます。

まず、なぜツールを審査から除外するのですか? 心を開いてあらゆる可能性を検討し、最良のものを選択することが重要だと思います。

第二に、プロジェクトによってはあるツールが別のツールよりも優れていると思いますが、別のプロジェクトではその逆になる可能性があります。あるツールが常に別のツールよりも優れているとは思いません。結局のところ、特効薬はありません。

あなたの質問に答えるには - はい、いいえ。それはプロジェクトと、チームが 1 つのツールにどれだけ精通しているかによって異なります。チーム全体が log4j に非常に慣れていて、すべてのニーズを満たし、logback がタスクを完了するために必要なものを何も提供しない場合は、「log4j を使用しないでください」とは言いません。

于 2008-10-07T14:58:45.500 に答える