1

サーバーにrest-requestをラップし、エラーをログに記録するためのクライアントライブラリを提供して、クライアントがアプリでそれを使用し、ログを表示できるようにします。(エラーをログに記録するか、再スローするかという質問もあります。非同期呼び出し(マルチスレッド)を使用する場合、これは非常に難しい場合があります。)

ライブラリを使用しているクライアントは、好みのログフレームワークを選択できるため、slf4jが役立つ可能性があることを読みました。

このslf4j-thingについて何かが私を困惑させます。彼が私のライブラリを取得し、私が提供した場合、たとえばslf4j-apiの場合、エラーがスローされ、SLF4Jバインディングが含まれていません。解決策は、彼が自分でバインディングを含める必要があるということかもしれません。問題は、この重要な情報についてREADMEを読んでも構わないと思っているかどうかです。

1つの「標準」-slf4jバインディング(たとえば、単純なもの)を含めると、クラスパスで許可されるバインディングは1つだけなので、アプリはこれを「オーバーライド」できません。柔軟ではありません

だから私はlog4jを使用して、他のすべてのロギングフレームワークを忘れることを考えています。私はこのテーマについて複雑に思うかもしれません、多分誰かがこれについて私を助けてくれるかもしれませんか?

4

1 に答える 1

6

ライブラリはラッピングアプリケーションのクラスパスを設定しないことを覚えておく必要があります。ラッピングアプリケーションは、ライブラリ、slf4j APIライブラリ、および実装ライブラリを含むクラスパスを設定します。

ラッピングアプリケーションは、どのslf4j実装を使用するかを処理し、すべてのロギングパラメーターをセットアップします。slf4jAPIを使用してライブラリイベントをログに記録することだけを心配する必要があります。これは一般的な方法です。ラッピングアプリケーションについて心配する必要はありません。

ライブラリ内にlog4jをパッケージ化することで、ロギングファサードの目的を無効にすることになります。そうすることで、ユーザーはslf4j実装を選択できなくなります。

于 2012-07-30T20:10:39.467 に答える