Loggingのメモ - システム開発で思うところ

JavaのLoggerは実装ライブラリを、DIなどで置き換えられるようにインターフェースと実装を分離させるようなことはしない方が良い気がする。
理由は、既に十分に抽象化で混とんとしているから。
とりあえず~~標準Loggerをインターフェースとして~~標準Loggerは実装クラスなので実装置き換えということは出来ませんが、slf4jを使うことにしたときに一気に書き換えをするという割り切りをしておけばいいかなと今は考えています。
それに基本的なLoggingについては、Interceptor経由で出力する前提で考えているから影響範囲もかなり限定的だと思っています。

メモ２

資料を参考に注意することなどの整理*1

Loggerはstatic final なフィールドで保持して強参照にする*2
Logger生成時に強制的にRootLogger配下に属するようにするべき？
Formatterを作って出力情報をきちんとする
FileHandlerは独自のFileHandlerを作って出力先を振り分けできる
WebApplicationの場合はLoggerのCloseをする
設定情報はpropertiesを参照する仕組みとして独自のpropertiesがない場合の考慮も忘れずに
Formatterは共通実装で良い（が良い）
Handlerで出力制御が確定する
EEサーバー固有のpropertiesと衝突するのでLogManager.getLogManager().readConfiguration()を使ってはいけない
各種制御をするのは独自パーツのみと割り切る（各種環境設定との衝突を避ける）
ログ出力制御はpropertiesもあるけど、Filterもある。独自制御の場合はFilterの方が良いかもしれない

メモ（Payara）

独自ログの出力先指定は絶対パス指定にする。
相対パスだと C:\payara5\glassfish\domains\domain1\config配下に作成されるので注意すること。
独自フォーマットは標準出力としてはエラー扱いになる？
多分、これが根拠になりそう。
GlassFish 4.1 のロギング (ja) - notepad

こうなるともはや JULはミドル用のLoggerで、LogBackなどのライブラリをアプリケーション用のLoggerとして使うとして大きく振り切った方が安全な気がしてきた。
欠点は、Payaraだと LogViewerが使えたりするけど、その恩恵も捨てるということになるところ。まぁLog監視はそもそもPayaraでやらずにログ監視用サーバーでやるべきかもしれない。

FileHanderについては指定したフォーマットをそのまま使ってくれているようだということは確認が出来ているので及第点かなぁ。