Red Hat Web Application Framework 6.1 Manuale Utente

Using

System.out.println()

for logging has numerous drawbacks.

1. It degrades performance. There is no easy way to conditionally turn off logging statements

system-wide, without resorting to error-prone and maintenance-intensive workarounds such as:

if (DEBUG) {

System.err.println("foo=" + foo);

}

where DEBUG is a system-wide boolean parameter that you can easily set to true or false.

2. Even with the above workaround, you don’t get a fine-grained degree of control. The logging is

either on, or off across the board. You could, of course, introduce more than one system-wide

flag, like so:

if (WARN) {

System.out.println("warn: bar=" + bar);

}

3. You are constrained to outputting only to the standard out and error devices. What if you need

to output to rotated log files? Additional custom code is required to support this requirement.

Going down this path slowly but surely, you may end up developing a general-purpose logging library.

Rather than reinventing the wheel, WAF relies on the

Log4J library from the Jakarta project of the

Apache Foundation. If you are not familiar with it, please skim through the online documentation at

http://jakarta.apache.org/log4j/docs/. The rest of this document tries to highlight rather than explain

the most salient

Log4J features.

The key abstractions that

Log4J provides are:

1. Ability to log to multiple devices. See the Javadoc for the

Appender

1

interface and its im-

plementing subclasses. There are many types of appenders included in

Log4J: file appender,

rolling file appender, remote syslog daemon appender, asynchronous appender, etc. Appenders

are fairly easy to extend for special purposes. For instance, you could write a database appen-

der. (In fact, several have already been written.) See Section 7.5.4 Custom Appenders for more

discussion on this.

2. Ability to easily configure the format of the message. For example, each message can automat-

ically include the timestamp, thread name, location (file name and line number), full or abbre-

viated class and method name from the which the message originated, etc. See the Javadoc for

Layout

(at http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Layout.html) and its sub-

classes.

3. API for logging errors and exceptions. See Section 7.5.2 Always log the Throwable.
4. Different logging levels. The minimum set of possible levels are

off

,

fatal

,

error

,

warn

,

info

,

debug

, and

all

. Extending the list of levels is possible but discouraged. You can change

the requested level of logging either by altering your configuration files before system startup,

or at runtime. More on this in Section 7.5.3 Runtime logging level manipulation. See also the

Javadoc for

Level

(http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html).

5. Fine-grained hierarchy of loggers. A logger is the central class that performs all logging op-

erations. Loggers are named with dot-delimited names like

foo.bar.baz

or

foo.bar.quux

.

Loggers form a hierarchy based on their names. You can configure and manipulate loggers in

bulk by referring to their parent names. For example, both

foo.bar.baz

or

foo.bar.quux

are children of

foo.bar.

Each logger has an associated logging level. By setting the logger’s level, you can control the

amount of information logged. Log statements are enabled only if the level of statement is

1. http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Appender.html