2

slf4j と logback を使用していくつかのプロジェクト用のロガーを構築しています。ロガーに付属する機能に加えて、ロガーにさらにいくつかのメソッドを追加したいと考えています: log.debug(String key, String[] params, Throwable throwable ) (情報、警告、エラーについても同じ)。キーはリソース ファイルから文字列を取得し、String[] からのパラメーターを入力してログに記録します。
ユーザーにはクリーンな slf4j を使用してもらい、可能であればログバックに縛られないようにしたいと考えています。私は自分の機能でログバックを拡張し、拡張された新しいログバックに slf4j のバインディングを書くことを考えていました。
それは正しい方法ですか？もしそうなら、どうすればlogbackを拡張できますか?
他のバインディングを見ると、マーカーを実装していないことがわかります。何かにバインドする例はありますか? それで、それを「logback extended」バインディングのスケルトンとして使用できますか?

4

2 に答える 2

1

org.slf4j.Logger を新しいインターフェースで拡張し、そのインターフェースを実装しました。私のロガーを使用するプロジェクトは、ログバックからの切り替えがうまくいかない場合に備えて、コードを変更する必要はありません。もちろん、実装は、追加されたメソッドを除いて、単純に slf4j 実装にルーティングされます。

于 2013-08-04T13:37:25.823 に答える
1

SLF4J には、例外を報告するためのすべての引数を 1 つにまとめた方法がないことに同意しますが、他のタイプ (info、warn...) では必要ないと思います。

LoggerWrapperこれらのメソッドを持つユーティリティ クラスを作成できます。

class LoggerWrapper extends Logger {
    private Logger logger;
    private ResourceBundle bundle;

    public LoggerWrapper(Logger logger, ResourceBundle bundle) {
        this.logger = logger;
        this.bundle = bundle;
    }

    public void error(final String key, Object[] params, Throwable cause) {
        logger.error(String.format(bundle.getString(key), params), cause);
    }
    ...
}

使用例:

class Something {
    private static LoggerWrapper logger = new LoggerWrapper(
            Logger.getLog(Something.class),
            ResourceBundle.getBundle("ErrorMessages"));

    ...
    private void doSomething(Object params...) {
        try {
            // Do something that could fail.
        }
        catch (SomeException e) {
            logger.error("error.something.failed", params, e);
        }
    }
}
于 2013-07-30T13:03:32.407 に答える