Java Logging Overview

by Steven J. Owens (unless otherwise attributed)

Java Logging Overview

I did a little looking into the JDK 1.4 logging API. Nothing special in the API itself, it reminds me a lot of the log4j API http://jakarta.apache.org/log4j/docs/manual.html), with a few trivial differences.

Initial Conclusion

Given that the APIs are extremely similar, I'm torn between wanting to adopt the imminent "blessed" standard (JDK 1.4) and adopting the defacto standard (log4j). My conclusion is that it won't make much difference either way. But, since we have to download a separate logging API anyway, why not go with the one that is open source, is in common use and has more support available, which would be log4j.

When I looked at the log4j API it was just after we'd developed a set of logging classes at my previous company, so I was looking for some good reason to move to the log4j API. I didn't see anything especially impressive at the time. On the other hand, a year later there are more adaptors and add-ons for log4j; still nothing earth-shattering, but some good solid work. This reinforces my conclusion (at the bottom of this page) that using any logging API is more than half the battle.

The basic layout of both APIs is the same:

JDK 1.4        log4j          Description
loggers        categories     structural organization of log messages
levels         priorities     importance organization of log messages
handlers       appenders      determines which messages to listen to
formatters     layouts        formats output of log messages

In A Nutshell

1. You configure a hierarchy of categories, they get instantiated as distinct objects and managed by a singleton that routes all log messages to the named object in the hierarchy.
2. You insert log calls throughout your code, each call using a specified category and priority.
3. You also configure handlers that listen to selected categories and do something with their messages (write to a console, save to a file, etc).
4. Finally, the log messages contain somewhat structured data and you use formatters/layouts to display them.

The loggers/categories objects are a hierarchy of categories configured with dot-separated name Strings, much the same way java packages are named. They provide a dimension of organization that is orthogonal to the levels/priorities. This dimension can be anything really but is assumed to usually be based on the structure of the program (e.g. package names, etc).

The loggers/categories are instantiated as a tree of objects, which are then accessed via a singleton root manager.

The jdk1.4 logging API also provides support for anonymous loggers, i.e. loggers that are not part of the singleton-managed tree. The author of log4j dismisses this as not particularly useful.

The levels/priorities are pretty much what you'd assume, numeric values with associated descriptive names to indicate the importance of the log message.

The handlers/appenders provide multiplexing and filtering of log messages and deliver the messages to different outputs.

The log4j project reportedly has a greater variety of appenders with support for logging to console, files, GUI components, remote socket servers, jms messages, NT event loggers and remote unix syslog daemons, and asynchronous logging.

The JDK 1.4 logging api provides a console, output stream, file, remote sockets, and in-memory handler (the in-memory handler looks like it provides asynchronous logging, i.e. when the buffer fills up it dispatches the messages to another handler, presumably a file handler or something).

Random Thought

One thing I've wondered repeatedly is why nobody has developed a logging API based on java's event model.

Something Sorta Nifty

One interesting looking bit for the JDK 1.4 logging API is that, if called without class/method arguments, it will try to guess which class and method the log came from. On the other hand, this is not reliable, especially with optimizing compilers, etc.

Earlier JDK Support

There's absolutely nothing on sun's site about logging support for earlier JDKs, however the "Lumberjack" project is a clean-room, open-source implementation of the API for use with earlier APIs.

Other Commentary

The principal author of log4j has some criticisms of the logging API. His more serious earlier criticisms have mostly been addressed in the most recent draft of log4J but he still has some issues:

Application Servers

One point to consider for people working with application servers (and possibly servlet engines, though less so) is that if and when their application server provider decides to do anything fancy with logging APIs, they will likely do it with the JDK 1.4 logging API.

On the other hand, one of the more cogent criticisms of the JDK 1.4 logging API is that it doesn't support - nor intend to support - any sort of remote or distributed logging.

The Zoo LV2 logging API looks like a candidate in that direction ( http://www.swzoo.org/log2/documents/intro.html). In particular, while LV2 appears to be significantly more complex (though their docs claim to have a gentle slope intro) it includes JINI support.

Conclusion

Overall, the most important thing is to create a logging structure and start using it - the cost of switching to a new logging scheme at a later date is likely to be a lot less than the cost of switching from System.out.println() calls. We ended up deciding to go with log4j.

Feedback

Verification Image:
Subject:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator. Message Content: