log4j対ログバック
自作のラッパーの背後でlog4jを使用しています。現在、より多くの機能を使用する予定です。
Logbackに更新する必要がありますか？
（フレームワークは、SLF4Jのようなファサードではありません）
LogbackはSLF4J APIをネイティブに実装します。これは、logbackを使用している場合、実際にはSLF4J APIを使用していることを意味します。理論的には、logback APIの内部を直接ログに使用することもできますが、それは非常に推奨されません。ロガーに関するすべてのログバックドキュメントと例は、SLF4J APIの観点から書かれています。
そのため、logbackを使用すると、実際にSLF4Jを使用することになり、何らかの理由でlog4jに切り替える場合は、slf4j-log4j12.jarをクラスパスにドロップするだけで数分以内に切り替えることができます。
Logbackからlog4jに移行する場合、特定の部分、特にlogback.xml構成ファイルに含まれる部分をlogbackに対応するlog4jに移行する必要があります。 log4j.properties。他の方向に移行する場合、log4j構成、つまりlog4j.propertiesは、同等のlogbackに変換する必要があります。 オンラインツール があります。構成ファイルの移行に伴う作業量は、すべてのソフトウェアのソースコードとその依存関係全体に散らばっているロガーコールを移行するために必要な作業よりもmuch少ないです。
あなたは？ はい。
どうして？ 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の次の例のように、多くのNice APIシュガーを提供します。
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
それは変数置換です。これはLog4j 2でもサポートされています。
ただし、slf4jはQOSによって開発され、logbackも維持していることに注意する必要があります。 Log4j 2.0は、Apache Software Foundationで作成されています。過去3年間で、活気に満ちた活発なコミュニティが再び成長しました。 Apache Software Foundationがすべての保証付きで行っているオープンソースを高く評価するなら、Log4j 2を直接使用することを支持してslf4jの使用を再検討するかもしれません。
ご注意ください：
過去において、logbackは維持されていましたが、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とほとんど何も共有せず、Logbackとゼロを共有します。これにより、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のVPであり、log4jにも関与しています。
あなたの質問に正確に答えているわけではありませんが、自分で作ったラッパーから離れることができる場合は、 Simple Logging Facade for Java（SLF4J） があります。コモンズロギング）。
SLF4Jは、Jakarta Commons Logging（JCL）で観察されるクラスローダーの問題やメモリリークの影響を受けません。
SLF4Jは、JDKロギング、log4jおよびlogbackをサポートしています。そのため、適切なタイミングでlog4jからlogbackに切り替えるのはかなり簡単です。
編集：私は自分自身を明確にしていない謝罪。 SLF4Jを使用して、log4jとlogbackの間で難しい選択をする必要から自分を隔離することを提案していました。
あなたの決定はに基づいている必要があります
- これらの「より多くの機能」に対する実際のニーズ。そして
- 変更を実装するための予想コスト。
「より新しく、より美しく、より良い」という理由だけで、APIを変更する衝動に抵抗する必要があります。私は「壊れていないなら、蹴らないでください」という方針に従います。
アプリケーションで非常に高度なロギングフレームワークが必要な場合は、その理由を検討してください。
成熟したプロジェクト、または開発段階の奥深くにあるプロジェクトでさえ、おそらくこのようなアップグレードから得られる以上のことを失うでしょう。確かに、ログバックは一連の点ではるかに高度ですが、稼働中のシステムで完全に置き換えるほどではありません。私は確かに新しい開発のためにlogbackを検討しますが、既存のlog4jはすでにリリースされ、エンドユーザーに会ったものには十分で成熟しています。これは非常に主観的なものであり、自分でコストをかける必要があります。