| MAP | PTLog ドキュメント > 動機 |
このドキュメントは、 PTLog 開発に至る動機に関して説明します。
本節では、ログフレームワークに対する、 以下に示す「私の」要求について説明します。
これはあくまで「私の」要求ですので、 「あなたの」要求ではないかもしれませんが、 多くの人が同様な要求を持っているものと考えています。
最近は、 幾つかのメジャーなログフレームワークが存在します。 著名なものとして、 JDK Logging API、 Apache Log4j および Jakarta Commons Logging があげられるでしょう。
そのため、 どのログフレームワークを選択すべきかは、 実行環境（例: アプリケーションサーバ）や、 共に利用されるライブラリ（例: DBMS アクセス、プレゼンテーション自動化等） のログフレームワーク利用状況に依存します。
そのため、 以下のような要求を満たすような、 基底(underlying)ログフレームワークの "差し替え可能性" が必要です。
ログ出力を分類するために、 固有の分類を定義したいです。
"固有の分類" とは、 一般的なログフレームワークにおける "固有のレベル(level)" とほぼ同義です。
ほぼ全てのログフレームワークでは、 スカラー値の "ログレベル" をログ出力の閾値（＝ 分類）として使用しています。
例えば、 "SQLDebug"、"NetworkDebug" および "LogicDebug" レベルを定義したとします。
コンパイル時にどのレベルの優先度が他よりも高いかを決定できますか？ SQL 実装に着目している際には "SQLDebug" の優先度が他よりも高いでしょう。 しかし、他の状況では、"NetworkDebug" ないし "LogicDebug" の優先度が高いかもしれません。
各レベルの間での優先度は、 開発／保守のフェーズに依存しているように見受けられます。
そのため、 半順序関係を許容する分類階層が必要です。
それに加えて、 時には "SQLDebug"、"NetworkDebug" および "LogicDebug" の全てを、 "Debug" として扱いたい場合もあります。
そして、この目的には Java のクラス階層がフィットするように思われます。 そこで、"スカラー値ベースの分類" に相対するものとして、 Java のクラス階層を用いたものを "型ベースの分類" と呼びます。
勿論、各分類間での優先度を実行時に確定するための機構も必要です。
例えば、 数値を16進数形式で整形したい場合があります。
時には明示的に整形形式を指定したいこともありますが、 時には全ての値をある形式で整形したいこともあります。
以下に示すような形式でメソッドのパラメータを出力したい場合があります。
p1=first,p2=second,p3=third,....
しかし私の知るログフレームワークは全て "+" 演算子による文字列片の結合を強制します。
logger.debug("p1=" + p1 + ",p2=" + p2 + ",p3=" + p3 ....);
情報を1レコードに詰め込むための、 よりエレガントな方法が必要です。
各ログフレームワークにおける要求充足性は以下のようになります。
| 要求 | JDK Logging API | Apache Log4j | JCL |
|---|---|---|---|
| 差し替え可能性 | no | no | yes |
| 固有の分類 | yes | yes | no |
| 型ベースの分類 | no | no | no |
| 値の整形 | no | no | no |
| 1レコードへの詰め込み | no | no | no |
全ての要求を満たすためには、 新規のフレームワークを自分自身で開発しなければならない、 という結論になりました。
| MAP | PTLog Documents > 動機 |