log4j対logback [終了]

自作のラッパーの背後でlog4jを使用しています。今後はさらに多くの機能を使用する予定です。

ログバックに更新する必要がありますか？

（つまり、フレームワークはSLF4Jのようなファサードではありません）

LogbackはSLF4J APIをネイティブに実装します。つまり、logbackを使用している場合は、実際にはSLF4J APIを使用しています。理論的には、logback APIの内部を直接ログに使用できますが、これはお勧めしません。ロガーに関するすべてのログバックのドキュメントと例は、SLF4J APIに関して記述されています。

したがって、logbackを使用すると、実際にはSLF4Jを使用することになります。何らかの理由でlog4jに戻したい場合は、slf4j-log4j12.jarをクラスパスにドロップするだけで、数分以内に戻すことができます。

logbackからlog4jに移行する場合、logback固有の部分、特にlogback.xml構成ファイルに含まれている部分は、同等のlog4j、つまりlog4j.propertiesに移行する必要があります。他の方向、log4jの構成に移行する場合、すなわちlog4j.propertiesは、そのlogback相当に変換する必要があります。そのためのオンラインツールがあります。構成ファイルの移行に伴う作業量は、ソフトウェアのすべてのソースコードとその依存関係全体に広まったロガー呼び出しを移行するために必要な作業よりもはるかに少ないです。

しますか？ はい。

どうして？ Log4Jは基本的にLogbackによって非推奨になりました。

緊急ですか？そうでないかもしれない。

痛くないですか？おそらく、それはあなたのロギングステートメントに依存するかもしれません。

LogBack（またはSLF4J）を最大限に活用したい場合は、適切なロギングステートメントを書く必要があることに注意してください。これにより、遅延評価によるコードの高速化、ガードの回避によるコード行の削減などの利点が得られます。

最後に、私はSLF4Jを強くお勧めします。（なぜあなた自身のファサードでホイールを再現するのですか？）

ロギングの世界には、ファサード（Apache Commons Logging、slf4j、またはLog4j 2.0 APIなど）と実装（Log4j 1 + 2、java.util.logging、TinyLog、Logback）があります。

基本的に、自分で作ったラッパーをslf4j IFに置き換える必要があります。何らかの理由で満足できない場合のみです。Apache Commons Loggingは実際には最新のAPIを提供していませんが、slf4jと新しいLog4j 2ファサードがそれを提供しています。かなりの数のアプリがslf4jをラッパーとして使用していることを考えると、それを使用することには意味があります。

slf4jは、slf4j docsの次の例のように、いくつかの素晴らしいAPIシュガーを提供します。

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

変数の置換です。これはLog4j 2でもサポートされています。

ただし、slf4jは、ログバックも維持するQOSによって開発されていることに注意する必要があります。Log4j 2.0は、Apache Software Foundationで作成されています。過去3年間で、活気のある活発なコミュニティが再び成長しました。Apache Software Foundationによってすべての保証が行われているオープンソースを高く評価している場合は、Log4j 2を直接使用することを優先して、slf4jを使用することを再検討することができます。

ご注意ください：

以前は、Log4の場合、log4j 1は積極的に保守されていませんでした。しかし、今日は状況が異なります。Log4j 2は積極的にメンテナンスされ、ほぼ定期的にリリースされます。また、多くの最新機能が含まれており、-imho-はLogbackよりもいくつかの点で優れています。これは時々好みの問題であり、あなた自身の結論を引き出す必要があります。

Log4j 2.0の新機能の概要を簡単に書きました：http ://www.grobmeier.de/the-new-log4j-2-0-05122012.html

読んでいると、Log4j 2はLogbackだけでなく他のロギングフレームワークにも触発されていることがわかります。しかし、コードベースは異なります。Log4j 1とはほとんど何も共有せず、Lo​​gbackとはゼロを共有します。これは、Log4j 2の例のようないくつかの改善につながり、内部では文字列の代わりにバイトストリームを使用します。また、再構成中にイベントが失われることもありません。

Log4j 2は、私が知っている他のフレームワークよりも高速でログを記録できます。http：//www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

それでも、ユーザーコミュニティはログバックよりもはるかに大きいようです：http ://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

最良のアイデアは、達成したいものに最適なロギングフレームワークを選択することです。本番環境でロギングを無効にして、アプリで基本的なロギングを実行するだけでは、完全なフレームワークを切り替えません。ただし、ロギングをもう少し行う場合は、フレームワークとその開発者が提供する機能を確認してください。QOSを介してLogbackの商用サポートを取得している間（聞いたところ）、Log4j 2の商用サポートは現在ありません。一方、監査ロギングを実行する必要があり、非同期アペンダーによって提供される高いパフォーマンスが必要な場合は、 log4jを確認します2。

彼らが提供するすべての快適さにもかかわらず、ファサードは常に少しパフォーマンスを食べることに注意してください。まったく影響がないかもしれませんが、リソースが不足している場合は、すべての情報を保存する必要があります。

要件をよく知らなければ、推奨を与えることはほとんど不可能です。ただ：多くの人が切り替えるからといって切り替えないでください。あなたはそれの価値を見ているからといって切り替えます。そして、log4jが死んでいるという主張はもう数えられません。生きていて暑いです。

免責事項：私は現在、Apache Logging ServicesのVPであり、log4jにも関わっています。

質問に正確に答えていませんが、自作のラッパーから離れることができる場合は、Hibernateが（Commons Loggingの代わりに）切り替えたSimple Logging Facade for Java（SLF4J）があります。

SLF4Jは、クラスローダーの問題や、Jakarta Commons Logging（JCL）で観察されるメモリリークの影響を受けません。

SLF4Jは、JDKロギング、log4j、およびlogbackをサポートしています。そのため、適切なタイミングでlog4jからlogbackに切り替えるのはかなり簡単です。

編集：私が明確にしていない謝罪。SLF4Jを使用して、log4jとlogbackのどちらかを選択する必要がないようにすることを提案しました。

あなたの決定は

• これらの「その他の機能」に対する実際のニーズ。そして
• 変更を実装するための予想コスト。

APIが「より新しく、より輝きがあり、より優れている」からといって、APIを変更したいという衝動に抵抗する必要があります。私は「壊れていなければ蹴らないでください」という方針に従います。

アプリケーションで非常に高度なロギングフレームワークが必要な場合は、その理由を検討することをお勧めします。

成熟したプロジェクト、または開発段階の深いプロジェクトでさえ、おそらくそのようなアップグレードから得られる利益よりも失うことになるでしょう。Logbackは確かに一連のポイントではるかに進んでいますが、実際のシステムでの完全な置き換えの範囲ではありません。私は確かに新しい開発のためにlogbackを検討しますが、既存のlog4jは十分に優れており、すでにリリースされてエンドユーザーに会ったすべてのものに対して成熟しています。これは非常に主観的なものであり、自分でコストを確認する必要があります。