web-dev-qa-db-ja.com

クラスごとのLog4jロガーとアプリケーションごとのロガー

ロガーの作成に関連する概念、特にJava EEのコンテキスト)の理解に行き詰まっています。

私の経験では、ほとんどの場合、アプリケーションごとに1つのロガーを使用しましたが、アプリケーションの特定の部分に特定のロガーが必要な場合はほとんどありませんでした。これらの場合にのみ、ラッパーを通じて新しいロガーを作成していました。そして、ロガーを呼び出したクラスの識別について話す場合、私は簡単なことをしていました:

public const String ThisIdentifier = "MyLoggerCallingClass";

そして、必要な追加のキーストロークがあったとしても、これをロガーメソッドにパラメーターとして渡していました。

現在、私は概念的な問題に直面しています。なぜ、アプリケーションごとではなくクラスごとにロガーを作成するのですか。
次の回答が見つかりました:

ロガーを初期化する最良の方法

クラスごとのロガーが推奨される理由

ただし、この情報を getLoggerのApacheドキュメント から取得した場合:

Nameパラメータの値に従って名前が付けられたロガーを取得します。指定されたロガーがすでに存在する場合、既存のインスタンスが返されます。それ以外の場合は、新しいインスタンスが作成されます。

クラスごとの方法を実行すると、Java EEアプリケーションに50個のパッケージがあり、パッケージごとに10個のクラスがあるとすると、アプリに500個のロガーインスタンスがあることになります。

私はC、C++、およびC#の観点から来ており、常に私の頭の中には次のものがあります。
「メモリは控えめに使用し、必要に応じてインスタンスを作成し、自分でクリーンアップし、乱用しないでください...」

ロガー作成の実際の詳細はわかりません。ログ結果をより適切にフィルタリングできるという考え方は理解できますが、そのようにする理由と、最終的にはインスタンスごとにインスタンスを作成することの有用性について誰にでも説明できますクラスでは、パラメーターを指定してロガーメソッドを呼び出すだけでなく、なぜメモリを浪費して多くのインスタンスを作成するのでしょうか。

[〜#〜]編集[〜#〜]

多分それは本当ですが、一般的に人々は多くのいわゆる「軽量」ロガーインスタンスが作成されることを気にしないということですが、私はプロジェクトの同僚と一緒にlog4jのラッパークラスを作成することになりました。ロガーを使用する。このラッパークラスには、デフォルトでロガーの単一インスタンスへの参照が含まれています

Logger.getLogger(Wrapperclass.getName())

また、この特定のロガーが呼び出されるクラスの名前。ロギングクラス名をログに記録します。特定のクラスをログに記録する必要がある場合は、変更するだけです

Logger.getLogger(Wrapperclass.getName())

Logger.getLogger(Callingclass.getName())

アプリを再構築して実行します。私の意見では、このソリューションはよりクリーンで整然としています。

編集2:

判明 これ

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

「メモリフットプリントが小さい」というフレーズをはっきりと見ることができる上記の引用に基づいて、私の疑いはそれほど誤っていなかったと結論付けることができます。チームで、log4jで必要とするのと同じロギング機能を実現できる場合は、logbackに切り替えるという考えを考慮します。

この質問が他の人が正しい決定をするのに役立つことを願っています!

6
XMight

Wordの「ロガー」の意味とLog4Jフレームワークの「ロガー」の意味が一致していないようです。

Log4Jフレームワーク内では、ロガーは非常に無駄のないクラスです。使用するThisIdentifierのラッパーと、ロギングステートメントを生成する関数のコンテナーにすぎません。
ログ記録のすべての重労働は、アペンダー、フィルター、レイアウトで発生します。

Log4Jアーキテクチャ で述べたように

ロガー

前述のように、ロガーはLogManager.getLoggerを呼び出すことによって作成されます。ロガー自体は直接アクションを実行しません。単に名前があり、LoggerConfigに関連付けられています。 AbstractLoggerを拡張し、必要なメソッドを実装します。構成が変更されると、ロガーが別のLoggerConfigに関連付けられ、その動作が変更される可能性があります。

したがって、数百のLoggerインスタンスが存在しても、システムに重大な影響を与えることはありません。