システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る

Loggingのメモ

参考資料


まずは、この記事を きちんと読む
java.util.loggingの使い方 - Qiita

そのあとで、この記事を読む
JUL を少しマシにする - A Memorandum


入門から実践までJavaで学べる「ログ」の常識 (1/4):プログラマーの常識をJavaで身につける(10) - @IT

[Java] 標準APIのLoggerを使用してログを外部ファイルに出力する。 | DevelopersIO

7.1. ロギング — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.2.1.RELEASE documentation

CDIのInjectionPointを使ってみる - CLOVER🍀

JavaEE7をはじめよう(18) - CDI インターセプターとステレオタイプ - エンタープライズギークス (Enterprise Geeks)

Java EEのCDIで定義しておくと便利なプロデューサーとインターセプタ - きしだのはてな

Java TM ロギングの概要

アプリへのslf4j + logback 導入時の java.util.logging 向け対処 - Qiita

[Java]Java SE標準ロギングのプロパティ設定で複数のファイルにログを分けて出力する - torutkのブログ

Java EE インジェクト可能なロガーの作り方と注意点 - Qiita

ログレベルが突然変わる謎の事象を追う ~ あるOSSサポートエンジニアの1日 - Qiita

Payara のログ・ビューワの制限事項 (ja) - notepad

java - 複数のパラメータによるロギング - 答えた

java.util.logging - FileHandler.patternで指定したディレクトリを作成する - Kazzzの日記

logging - Java - configure custom loggers for use - Stack Overflow

メモ

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

メモ2

資料を参考に注意することなどの整理*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については指定したフォーマットをそのまま使ってくれているようだということは確認が出来ているので及第点かなぁ。

Code

Loggerの実装についてコミットログ(雑に)

vermeer_etc / jsf-ddd / commit / 006cd7411230 — Bitbucket


*1:当たり前を当たり前として認識することも含めて

*2:そうしないとGCでLoggerインスタンスが破棄される可能性がある