log 4 j簡明マニュアル下

servletの初期化
log 4 jの初期化には、特別なservletを使用することもできる.次に例を示します.

package com.foo;

import org.apache.log4j.PropertyConfigurator;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;

public class Log4jInit extends HttpServlet {

  public
  void init()
 {
    String prefix =  getServletContext().getRealPath("/");
    String file = getInitParameter("log4j-init-file");
    // if the log4j-init-file is not set, then no point in trying
    if(file != null) {
      PropertyConfigurator.configure(prefix+file);
    }
  }

  public
  void doGet(HttpServletRequest req, HttpServletResponse res) {
  }
}

Web.xmlファイルで、次のservletをネットワークアプリケーションに定義します.

  <servlet>
    <servlet-name>log4j-init</servlet-name>
    <servlet-class>com.foo.Log4jInit</servlet-class>

    <init-param>
      <param-name>log4j-init-file</param-name>
      <param-value>WEB-INF/classes/log4j.lcf</param-value>
    </init-param>

    <load-on-startup>1</load-on-startup>

  </servlet>

initialization servletを記述することはlog 4 jを初期化するために最も柔軟な方法である.制限されず、このservletのinit()メソッドに任意のコードを入れることができます.
Nested Diagnostic Contexts
実際のシステムの多くは、複数のクライアントの問題を同時に処理する必要があります.このようなシステムの典型的なマルチスレッド実装では、通常、異なるスレッドが異なる顧客ニーズをそれぞれ処理する.Loggingは特に複雑なプログラム追跡とエラーの排出に適している.1つの一般的な処理方法は、各顧客に新しい分離されたloggerを生成することによって、異なる顧客のログ出力情報を区別することである.しかし、これはloggersの増殖を促進し、loggingの管理負担を増大させた.
より簡潔なテクノロジーは、同じ顧客からの各ログリクエストをユニークにマークすることです.Neil Harrisonは彼の本の中で「Patterns for Logging Diagnostic Messages」in Pattern Languages of Program Design 3,edited by R.Martin,D.Riehle,and F.Buschmann(Addison-Wesley,1997)がこの方法を説明した. Pattern Languages of Program Design 3
各ログ要求をユニークにマークするには、ユーザがコンテキスト情報をNDCに送る.NDCはNested Diagnostic Contextの略である.NDC類は以下のように展示されている.

  public class NDC {
    // Used when printing the diagnostic
    public static
 String get();

    // Remove the top of the context from the NDC.
    public static
 String pop();

    // Add diagnostic context for the current thread.
    public static
 void push(String message);

    // Remove the diagnostic context for this thread.
    public static
 void remove();
  }

NDCクラスは、スレッドコンテキストを保存するstackとして、単一スレッド(per thread)で管理される.org.apache.log4j.NDCクラスのすべての方法は静的であることに注意してください.NDC印刷機能がオンになっていると仮定し、ログ要求があるたびに、対応するlog 4 jコンポーネントは、この現在のスレッドのNDC stack全体をログ出力に含めて印刷する.このようにしてユーザの介入を必要とせず,ユーザはコードに明確に指定されたいくつかの点でpushとpopの方法で正しい情報をNDCに置けばよい.逆に、per-client loggerメソッドはコードに多くの変更を加える必要があります.
この点を説明するために,servletが複数のクライアントに情報内容を送信する例を挙げる.このサーブレットプログラムは、クライアントからの要求を受け、他のコードを実行する前に、まずNDCを作成します.このコンテキスト情報は、クライアントのホスト名、および他のリクエストに固有の情報であり、通常はcookiesに含まれる情報である.したがって、このサーブレットプログラムは、複数のクライアントに同時にサービスを提供し、同じコードで起動されたこれらのlogs、例えば同じloggerに属しても、異なるクライアント要求が異なるNDC stackを有するため、区別することができる.これは、顧客要求中にインスタンス化されたloggerを実行するすべてのコードに渡す複雑さとは対照的である.
しかし、仮想ネットワークサーバなどの複雑なアプリケーションでは、仮想ホストのコンテキスト言語環境や、リクエストをパブリッシュするソフトウェアコンポーネントに基づいて異なるlogを作成する必要があります.最近のlog 4 jリリースでは、多層ツリーがサポートされています.この機能の強化により、各仮想ホストが独自のlogger階層バージョンを持つことができます.
パフォーマンス
よく提起される議論はloggingの演算オーバーヘッドである.このような関心は、中程度のアプリケーションでも少なくとも数千個のlog出力が発生するため、理にかなっている.多くの作業はlogging性能の測定と改善に費やされている.Log 4 jはそれが迅速で柔軟であることを宣言した:速度が第一で、柔軟性が第二である.
ユーザーは、次のようなパフォーマンスに関する問題を明確に理解する必要があります.

Logging performance when logging is turned off.loggingが完全に閉じられた場合、またはset of levelsだけが閉じられた場合、ログ要求のオーバーヘッドはメソッドの呼び出しと整数の比較である.233 MHz Pentium IIマシンでは、このオーバーヘッドは通常5 to 50ミリ秒の範囲内である.  set of levelsただし、メソッドの呼び出しには、パラメータのある構築上の「隠し」オーバーヘッドが含まれます.例えば、次のlogger catプログラムセグメントでは、

     logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
    

は、メッセージがログに記録されるかどうかにかかわらず、メッセージパラメータを構築するオーバーヘッドがあり、例えば、整数iと配列entry[i]をStringに変換し、中間文字列を接続する.パラメータ構造のこのオーバーヘッドは、介入するパラメータの数に依存して高い可能性があります.このようなパラメータ構造のオーバーヘッドを回避するために、以上のコードセグメントを

      if(logger.isDebugEnabled() {
        logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
      }
   

に書き換え、エラー機能が使用されなければ、パラメータ構造上のオーバーヘッドは発生しない.しかし、一方で、loggerの並べ替え機能が起用されると、loggerが起用されたかどうかを評価するのに2倍のコストがかかります.1回はdebug Enabled、1 はdebugが されたかどうかを します.しかし、これは、loggerを する がlog の の1%に ぎないため、log 4 jではログ をLoggerクラスの としている.Loggerはインタフェースではなくクラスであり,これは にプログラム び しのオーバーヘッドを するためであるが,インタフェースがもたらす を にしている. のユーザーは、 またはcompile-timeテクノロジーを してすべてのlog をコンパイルします.このようにlogging の はとても いです.しかし、resultingアプリケーションbinaryにはlog が まれていないため、このバイナリプログラムにloggingを することはできません. から れば、これは さな の のために きな を っている.

The performance of deciding whether to log or not to log when logging is turned on. に に する はloggerの である.logging が かれると、log 4 jは としてlog のレベルをrequest loggerのレベルと する がある.ただし、loggersの には が り てられていないものもありますが、 の のloggerから を することができます.したがって、 を する に、loggerはancestorsを する がある があります.Log 4 jはこの で きな をして、このような の レベルの (hierarchy walk)をできるだけ くするようにしました.たとえば、 loggersは、 のancestorsにのみリンクされます. のBasicConfigurator では、com.foo.Barと ばれるloggerはroot loggerに リンクされ、 しないcomまたはcom.foo loggersを している.これにより、 の が に します. の (walking the hierarchy)のオーバーヘッドは、loggingが に じたときより3 いことにある.

Actually outputting log messagesここではlog のフォーマットとlog をターゲット に するオーバーヘッドについて します.Log 4 jはこの でもフォーマットをできるだけ く できるように を れている.appendersにも じです. 、フォーマット のオーバーヘッドは、100～300マイクロ の である があります. な はorg.apache.log4.performance.Loggingを してください.

log 4 jは くの を するが、 は 1の である. を させるために、いくつかのlog 4 jの は も き えられたことがある.それでもlog 4 jの たちは しい を えず している.SimpleLayoutで されている 、パフォーマンステストではlog 4 jログの とSystem.out.printlnログの が じくらい いことに くべきです.

Log 4 jはJavaで された にポピュラーなlogging パッケージです.その な の つはloggersに の を したことである.このようなloggerの を いると, log の を に することができる.これにより、log の が し、loggingのオーバーヘッドが される.
Log 4 j APIの の1つは、その である.log がコードに されると、ソースコードを コンパイルすることなくプロファイルによって されます.ログ の は、ユーザが したフォーマットに って くの なる に することができるように、 に または にすることができる.Log 4 jパッケージの は,コードにlog を しながら きな をもたらさない.