java - log4j と logback

Question

自作のラッパーの背後で log4j を使用しています。現在、より多くの機能を使用する予定です。

logback に更新する必要がありますか?

(SLF4J のようなファサードではなく、フレームワークを意味します)

Answer 1

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 に変換する必要があります。そのためのオンラインツールがあります。構成ファイルの移行に必要な作業量は、ソフトウェアのすべてのソース コードとその依存関係全体に広まっているロガー呼び出しを移行するために必要な作業よりもはるかに少なくなります。

Answer 2

あなたはすべきですか？ はい。

なんで？ Log4Jは基本的にLogbackによって廃止されました。

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

無痛ですか？おそらくですが、ロギングステートメントに依存する場合があります。

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

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

Answer 3

ロギングの世界には、ファサード (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 は logback も管理している QOS によって開発されていることに注意する必要があります。Log4j 2.0 は Apache Software Foundation に組み込まれています。過去 3 年間で、活気に満ちた活発なコミュニティが再び成長しました。オープン ソースが Apache Software Foundation によってすべての保証とともに行われていることに感謝する場合は、Log4j 2 を直接使用するために slf4j を使用することを再検討するかもしれません。

ご注意ください：

過去には、log4j 1 は積極的に維持されていませんでしたが、Logback は維持されていました。しかし、今日は事情が異なります。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

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

最善のアイデアは、達成したいものに最適なロギング フレームワークを選択することです。本番環境でロギングを無効にして、アプリで基本的なロギングのみを実行する場合、完全なフレームワークを切り替えることはありません。ただし、ロギングをもう少し行う場合は、フレームワークとその開発者によって提供される機能を見てください。QOS を通じて Logback の商用サポートを得ることができますが (聞いたことがあります)、現在 Log4j 2 の商用サポートはありません。 log4j 2を確認してください。

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

要件をよく知らなければ、推奨することはほとんど不可能です。ただ: 多くの人が乗り換えるという理由だけで乗り換えないでください。価値があるという理由だけで切り替えてください。そして、log4j が死んでいるという議論はもはや数えられません。生きていて、暑いです。

免責事項: 私は現在、Apache Logging Services の副社長であり、log4j にも携わっています。

Answer 4

あなたの質問に正確に答えているわけではありませんが、自作のラッパーから離れることができれば、Hibernate が (コモンズ ロギングの代わりに) 切り替えたSimple Logging Facade for Java (SLF4J)があります。

SLF4J は、Jakarta Commons Logging (JCL) で見られるクラス ローダーの問題やメモリ リークの影響を受けません。

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

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

Answer 5

あなたの決定は、に基づいている必要があります

• これらの「より多くの機能」に対する実際の必要性; と
• 変更を実装するために予想されるコスト。

API が「より新しく、光沢があり、優れている」という理由だけで API を変更したいという衝動に抵抗する必要があります。「壊れていないものは蹴らない」というポリシーを持っています。

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

Answer 6

成熟したプロジェクト、または開発段階の深いプロジェクトでさえ、おそらくそのようなアップグレードから得られるものよりも多くのものを失うでしょう、IMHO。確かに、Logback はさまざまな点ではるかに高度ですが、稼働中のシステムで完全に置き換えるほどではありません。私は確かに新しい開発のためにlogbackを検討しますが、既存のlog4jは十分に優れており、すでにリリースされてエンドユーザーに会ったものに対して十分に成熟しています. これは非常に主観的なものです。コストは自分で確認してください。