Log4j日志组件 - 终极资料(2)

因此，配置一个日志记录器，不用在代码里转换引用就可以获得相同的实例是可能的。在生物学父时代的基本矛盾里面，总是可以preceed他们的孩子，log4j的日志记录器可以按一定的规则创建和配置。尤其是，即使一个“父”日志记录器在它的子孙后面被实例化，它仍然可以发现并连接到它的子孙

在应用程序初始化的时候，Log4j的配置被执行。最好的方法是通过读取一个配置文件。很快就会讨论这个方法 通过使用软件组件，log4j很容易命名日志记录器。这可以通过在每个类中静态实例化日志记录器来完成，日志记录器名是和完整的类名相同的。这是一个直截了当地定义日志记录器的有用方法。由于日志输出带有产生该日志的日志记录器的名称，命名策略让辨认产生日志消息的源头很容易。然而，这仅仅是是一个可能，虽然命名日后子记录器的策略很普通(However, this is only one possible, albeit common, strategy for naming loggers)。Log4j没有约束日志记录器可能趋势(Log4j does not restrict the possible set of loggers)。开发者可以很自由的根据需要命名日志记录器。

不过，在类后面命名日志记录器好像是目前所知最好的策略 输出源和布局器

基于日志记录器有选择地让日志请求是否起作用地能力仅仅描述(picture)地一部分.log4j允许日志请求输出到多个目标。在log4j地声明中，输出目的地被成为输出源(appender).最近，输出源包括控制然台、文件、GUI组件、远程套接字服务器(remote socket servers)、JMS、NT事件记录器(NT Event Loggers)和远程UNIX Syslog守护进程(remote UNIX Syslog daemons)。它也可以异步地记录日志。 一个日志记录器可以有多个输出源。

AddAppender方法加一个输出源到给定的日志记录器。对应给定的日志记录器每个激活的日志请求都将被转向到所有的输出源，因为这些输出源是和层次 (hierarchy) 中更高级别的输出源一样的。换句话说，输出源是被从日志记录器的层次附加继承的(appenders are inherited additively from the logger hierarchy)。例如，假如有一个控制台输出源被加到一个根日志记录器(root logger),最后所有被激活的日志请求都将打印在控制台上，另外，假如一个文件输出源被加到日志记录器，叫做C，然后激活到C和C的孩子的日志请求将输出到一个文件和控制台。覆盖这个默认的行为是可能，以便于通过设定附加标识为假，输出源的聚集不再是附加的。 管理输出源附加行为的规则将在下面总结。 输出源的附加特性 日志记录器C的日志语句的输出将定向到C和它的祖先中的所有的输出源。这是条款“输出源的附加特性(appender additivity)”的意图. 然而，假如有一个日志记录器C的祖先，叫做P，有一个附加标识被设置为false，然后C的输出将被定向到C和直到C的祖先P(包括P)中的所有的输出源，但是不包括P的祖先的中的任何输出源。 日志记录器有它自己附加特性，该特性被默认设置为true 下表展示了一个例子：

日志记录器

添加的输出源 A1

附加特性标

识 not

输出目标 评论

root A1 根日志记录器是匿名的，但是可以用

applicable

Logger.getRootLogger()方法来存取。根日志记录器没有默认输出源。

A1, A-x1, A-x2 A1, A-x1, A-x2 A1, A-x1, A-x2, A-xyz1 A-sec

x

A-x1, A-x2

true x和根的输出源

x.y none true x和根的输出源

x.y.z A-xyz1 true x.y.z 、x和根的输出源

security A-sec false 由于附加标识被设置为false，没有输出源聚集 由于安全中附加标识被设置为false，所以仅仅有安全的输出源。

security.access none true A-sec

时常，用户不仅希望自定义目的地，而且包括输出格式的自定义。这是通过给输出源设定一个布局器(layout)来到达目的地。

例如，带有\转换格式的PatternLayout布局器将输出和下面的内容类似。 176 [main] INFO org.foo.Bar - Located nearest gas station.

第一个字段是自从程序开始到目前花费的时间。第二个字段是发出日志请求的线程。第三个字段是日志语句的级别。第四个是和该日志请求关联的日志记录器的名称。紧接着“-”符号后面的内容是日志语句的消息。

正像这样重要，log4j将按用户指定的标准修饰(render,这样翻译，不知是否合适)日志信息的内容。例如，假如你经常需要记录Oranges,这是一个在你当前项目中使用的对象类别，你可以注册一个OrangeRenderer类，在某个orang需要记录日志的时候将调用OrangeRenderer类

对象的修饰(Object rendering)遵循类层次。例如，假定oranges是水果，若你注册了一个FruitRenderer类，包括所有的oranges水果都将被FruitRenderer类修饰，除非你给orange指定一个OrangeRenderer。 renderer对象必须实现ObjectRenderer接口 配置

插入应用程序代码的日志请求需要相当大的准备和努力。观察表明大约有4％的代码是用来输出日志的。结果，即使适度大小的应用程序也有数以千计的日志语句被嵌在代码中。给定他们数字，管理这些语句变成了急迫的事情，而不需要没有手工修改的。

Log4j的环境是完全参数化的配置。然而，用配置文件配置log4j是非常灵活的。目前，配置文件可以使用XML或者java属性文件(键值)格式

然我们尝试一下怎样用log4j 配置一个虚构的应用程序MyApp。

import com.foo.Bar; // Import log4j classes. import org.apache.log4j.Logger; import org.apache.log4j.BasicConfigurator; public class MyApp { // Define a static logger variable so that it references the // Logger instance named \ static Logger logger = Logger.getLogger(MyApp.class); public static void main(String[] args) { // Set up a simple configuration that logs on the console. BasicConfigurator.configure(); logger.info(\ Bar bar = new Bar(); bar.doIt(); logger.info(\ } } MyApp从导入相关类开始。它然后使用MyApp定义了一个静态的日志记录器变量，这个MyApp恰好是一个完整的类名。

MyApp用到了定义在com.foo包中的Bar类

package com.foo; import org.apache.log4j.Logger; public class Bar { static Logger logger = Logger.getLogger(Bar.class); public void doIt() { logger.debug(\ } } BasicConfigurator.configure方法的调用创建了一个比较简单的log4j设置。这个方法是硬连线(hardwired)地添加到根日志记录器的ConsoleAppender输出源。输出将使用布局器PatternLayout来格式化，布局器PatternLayout被设定为\的格式。 注意默认值，根日志记录器被设定为Level.DEBUG级别。 MyApp的输出是：

0 [main] INFO MyApp - Entering application.

36 [main] DEBUG com.foo.Bar - Did it again! 51 [main] INFO MyApp - Exiting application.

下面这个图描述了在调用BasicConfigurator.configure 方后之后MyApp的对象图

作为一个侧面的注意点，我要提及的是log4j中的子类仅仅连接到他们存在的祖先。特别的，名为com.foo.Bar的日志记录器被直接连接到根日志记录器，因而围绕在未使用的com或者com.foo日志记录器。这个显著地提高了性能，并且减少了log4j地内存消耗（footprint …… 此处隐藏：4341字，全部文档内容请下载后查看。喜欢就下载吧 ……