log4j权威指南：Ceki Gülcü著

需积分: 7 192 浏览量更新于2024-07-31 1 收藏 1.93MB PDF 举报

"The Complete Log4j Manual 是一本由 Ceki Gülcü 编写的关于 Apache Log4j 的详尽指南，适用于版本1.2及其后续版本。此手册基于2000年11月在JavaWorld杂志上发表的文章，并包含更详细且最新的信息。手册也借鉴了作者的其他相关著作内容。" Apache Log4j 是一个广泛使用的Java日志记录框架，它提供了强大的控制来管理应用程序的日志输出。这个完整的手册详细介绍了如何有效地利用Log4j进行日志记录，这对于任何Java开发者来说都是极其重要的工具，因为它可以帮助调试、监控和分析应用程序的行为。手册的主要内容可能包括以下几个关键知识点： 1. **配置介绍**：Log4j 的配置文件（通常为 `log4j.properties` 或 `log4j.xml`）是设置日志行为的核心部分。用户可以通过配置文件指定日志级别（如 DEBUG、INFO、WARN、ERROR 和 FATAL）、定义日志输出目的地（控制台、文件、数据库等）以及定制日志格式。 2. **日志级别**：理解每个日志级别的含义至关重要，因为这决定了哪些信息会被记录。DEBUG 用于调试，INFO 用于一般信息，WARN 表示可能的问题，ERROR 和 FATAL 表示严重错误。 3. **Logger**：Logger 是 Log4j 中的基本组件，用于生成日志记录。开发者可以创建多个 Logger 对象，每个对应应用程序的不同部分。 4. **Appender**：Appender 是负责将日志信息输出到特定目的地的对象，如控制台、文件、SMTP 邮件、syslog 服务器等。每个 Appender 可以有自己的布局，定义日志信息的格式。 5. **Layouts**：Layouts 决定了日志事件的输出格式，如 SimpleLayout、PatternLayout 和 HTMLLayout，它们分别提供简洁、自定义格式和HTML格式的输出。 6. **Filters**：Filter 功能允许根据特定条件过滤日志事件，如只让特定级别的日志通过或阻止某些日志记录。 7. **自定义日志记录**：开发者可以通过继承 `org.apache.log4j.Logger` 类并覆盖相应方法来自定义日志行为，以满足特定需求。 8. **性能考虑**：Log4j 提供了性能优化策略，例如日志级别检查可以在运行时避免不必要的日志操作，减少对应用程序性能的影响。 9. **日志管理和归档**：Log4j 还支持日志文件的滚动和归档，防止单个日志文件过大，便于长期存储和检索。 10. **集成与扩展**：Log4j 可以轻松地与其他Java项目集成，如Spring框架，也可以通过插件机制进行扩展。通过阅读 "The Complete Log4j Manual"，开发者不仅可以掌握如何配置和使用 Log4j，还能深入了解日志管理的最佳实践，从而提高代码质量和维护性。这本手册的授权条款允许个人下载和使用，但禁止未经许可的修改、分发和商业使用。

RECIPE FOR USING LOG4J IN YOUR APPLICATIONS 5

NOTE Log4j normally needs to be configured only once. Some new users try

to configure log4j in each and every class. This is very inefficient and

just plain wrong.

2. In every class where you wish to perform logging, retrieve a

Logger object

by invoking the

Logger.getLogger method and passing it a String,

commonly the fully qualified name of the containing class. This logger ob-

ject is usually declared as static final.

There is a variant of the

Logger.getLogger method that takes a Class

object as argument instead of a

String. It is intended as a syntactic sugar.

For some class

X in package com.wombat, the following three expressions

are equivalent:

Logger.getLogger("com.wombat.X"); // String variant

Logger.getLogger(X.class.getName()); // another String variant

Logger.getLogger(X.class); // convenient Class variant

3. Use this logger instance by invoking its printing methods, namely the de-

bug()

, info(), warn(), error() and fatal() methods or the more ge-

neric

log() method. This will produce logging output on selected devices.

Before delving into the details of log4j's architecture in the next chapter, it is a good

idea for the reader to try out the examples in this introductory chapter. As Fredic O.

Brooks observes in this classical work “The Mythical Man-Month”, donning a belt of

success, however modest, has extraordinarily positive effects on spirits.

8 CHAPTER 2: LOG4J ARCHITECTURE

Logger creation and retrieval

Each and every logger is tightly bound to the hierarchy that creates it. As mentioned

previously, all non-root loggers are instantiated and retrieved with the class static

Logger.getLogger

method that takes either a String or a Class argument. If

the logger does not exist it will be automatically created.

This method actually delegates its work to the appropriate logger repository. In other words,

it is a repository that takes care of the creation and retrieval of logger instances. Log4j comes

with a particular type of repository, the hierarchy that arranges loggers according to the

named-hierarchy rule. The only type of repository encountered in practice is the hierarchy. As

such, unless specified otherwise, I will use the terms “hierarchy” and “repository” inter-

changeably in the remainder of this manual. The logger repository can be set by a main appli-

cation such as a J2EE Application Server or a Servlet Container. The logger repository is a

very advanced concept. Normally, most users neither care about nor control the logger reposi-

tory they use. Chapter 8 discusses reasons for using multiple repositories. In many cases only

the default hierarchy is used. At this stage you should just ignore the possibility of using mul-

tiple repositories and just assume that you are using the default repository, a.k.a. the default

hierarchy.

package org.apache.log4j;

public class Logger {

// Logger creation & retrieval methods:

public static Logger getRootLogger();

public static Logger getLogger(String name);

// printing methods:

public void debug(Object message);

public void info(Object message);

public void warn(Object message);

public void error(Object message);

public void fatal(Object message);

// printing methods for logging exceptions:

public void debug(Object message, Throwable t);

public void info(Object message, Throwable t);

public void warn(Object message, Throwable t);

public void error(Object message, Throwable t);

public void fatal(Object message, Throwable t);

// generic printing method:

public void log(Level p, Object message);

}

LEVELS 9

One of the basic properties of the log4j framework is that calling the

Log-

ger.getLogger

method with the same name will always return a reference to the

exact same logger object. For example, in the following two statements

Logger x = Logger.getLogger("wombat");

Logger y = Logger.getLogger("wombat");

x and y refer to exactly the same logger object. It is thus possible to configure a log-

ger and then to retrieve the same instance somewhere else in the code without pass-

ing around references. In contrast to biological parenthood, where ancestors always

precede their descendants, log4j loggers can be created and configured in any order.

In particular, an ancestor logger will find and link to its descendants even if it is in-

stantiated after them.

Configuration of the log4j environment is typically done at application initialization.

The preferred way is by reading a configuration file. This approach will be discussed

in Chapter 3.

Log4j makes it easy to name loggers by software component. This can be accom-

plished by statically instantiating a logger in each class, with the logger name equal

to the fully qualified name of the class. This is a useful and straightforward method

of defining loggers. As the log output can be easily configured to bear the name of

the generating logger, this naming strategy makes it easy to identify the origin of a

log message. However, this is only one possible, albeit common, strategy for naming

loggers. Log4j does not impose any restriction on the name of loggers. The user is

free to name loggers as she wishes. Nevertheless, naming loggers after the class

where they are located seems to be the best strategy known so far.

Levels

Logging requests are made by invoking one of the printing methods of a logger in-

stance. These printing methods, namely

debug(), info(), warn(), error(), fa-

tal()

and log(), are member methods of the Logger class. Each of these methods

except the more generic

log() method corresponds to a built-in level. Levels

are

closely related to the importance of the log request as judged by the developer. The

In previous versions of log4j, we used the term priority instead of level. Consider the two

terms as synonyms. I consider the term priority to be more descriptive, but at the time of the

change it seemed more important to be aligned with “official” Java terminology. With hind-

sight, I can say that changing terminology is costly and this particular change was not worth

the effort.

剩余188页未读，继续阅读

junge2

粉丝: 20
资源: 29

log4j权威指南：Ceki Gülcü著

The Complete Log4j Manual

The Complete log4j Manual

log4j The Complete Manual

log4j the complete manual

Log4j The Complete Manual.pdf

log4j The Complete Manual (2002）

log4j Manual

log4j manual

[Online]log4j_The_Complete_Manual.zip

收藏Log4j文档

最新资源