3

DBIなどのいくつかのユーティリティクラス内でロギングを採用したいと思います。Log :: Log4perlでそれを行うためのベストプラクティスは何ですか？

DBI（たとえばMyDBI）をサブクラス化し、そこでいくつかのメソッドをオーバーライドして、ロギングを実行させるのは問題ないと思います。しかし、カテゴリには問題があります。でロガーを作成する場合

Log::Log4perl->get_logger(ref $self || $self)

その場合、すべてのログエントリが属し、MyDBIそれらをフィルタリングするのは困難です。MyDBIしたがって、呼び出し側モジュール（たとえば）からロガーを渡す方が良いように思われMyModuleます。そうすれば、カテゴリーは意味的に正しくなります。最初の質問、それは一般的に大丈夫ですか？つまり、そのようなアプローチに関して隠されたサンゴ礁はありますか？

2番目の質問、ロガーを渡す方法はMyDBI？グローバル変数を宣言するアイデアがあります。たとえば$MyDBI::logger、呼び出し元のメソッドで設定します。

local $MyDBI::logger = Log::Log4perl->get_logger(ref $self || $self);

グローバル変数には伝統的な嫌悪感があります。もっと良い方法を考えられますか？

編集：もちろん、最良のコードはコードなしです。caller継承を考慮に入れれば十分でしょう。

3番目の質問は、両方のカテゴリにログインすることは可能MyDBIですMyModuleか。階層的に関連がない場合は、Log :: Log4perlを使用してログインできますか？

4

1 に答える 1

2

呼び出し元で使用される log4perl とは独立してモジュールを実行できるように、関数ごとまたはモジュールごとに別のロガーで呼び出し元に個別にログを記録することを強くお勧めします。各モジュールは、 を使用して独自のロガーを作成しますLog::Log4perl->get_logger("module name")。
呼び出し元がアペンダーを作成しない場合、プログラムは単に何もログに記録せず、モジュール内の log4perl は機能的な観点から無視されます。
Log4Perl は、グローバル変数に似た、ロガーを作成するためのシングルトン パターンを実装します。
ロギングは可能な限り細かくする必要があり、経験則として、入力パラメーターと関数/メソッドの結果をデバッグします。本当に必要な場合は、スタック トレースを使用して、エラー状態の原因となった呼び出し元を見つけることもできます。それをパラメーターに追加しても、複雑さが増すだけです。

次のレシピは、log4perl の構成面での柔軟性に関するアイデアをさらに提供する可能性があります。Log4Perl レシピ私にとっての全体的なアイデアは、コードを変更せずに保持し、実際のロギング/バグ追跡の要件 (将来変更される可能性があります) に応じてロギング構成を変更することです。すべての呼び出しプログラムをテストすることを避けたいので、可能であればコードを変更しないでおくことがモジュールではさらに重要です。

あなたの質問に簡潔に答えるために。1.) 各モジュールには独自のロガーが必要です。 2.) したがって、ロガーをインターフェイスに追加しないでください。 3.) Log4Perl は、アペンダーの設定に応じてすべてのレベルでログを記録します。このようにして、表示されないものを制御します。通常のレベルは通常 INFO で、特定のモジュールがデバッグ中の場合があります。悪いケースでは、パターン レイアウトを使用すると、構成だけでスタック トレースをロギングに追加できます。

于 2010-03-09T08:42:26.657 に答える