Copyright © 2009 O'Reilly Media, Inc.
October 15, 2009
Abstract
Log4j has been around for a while now, and it seems like so many applications use it. I’ve used it in my applications for years now, and I’ll bet you have too. But every time I need to do something with log4j I’ve never done before I find myself searching for examples of how to do whatever that is, and I don’t usually have much luck. I believe the reason for this is that there is a not a great deal of useful information about log4j, either in print or on the Internet. The information is too simple to be of real-world use, too complicated to be distilled quickly (which is what most developers want) and/or not very well written and hard to understand. The purpose of this Short Cut is to hit the “sweet spot” that no other works currently do: the right balance between simplicity and useful information.
Log4j has been around for a while now, and it seems like so many applications use it. I’ve used it in my applications for years now, and I’ll bet you have too. But every time I need to do something with log4j I’ve never done before, I find myself searching for examples of how to do whatever that is, and I don’t usually have much luck. I believe the reason for this is that there is a not a great deal of useful information about log4j, either in print or on the Internet. The information is too simple to be of real-world use, too complicated to be distilled quickly (which is what most developers want) and/or not very well written and hard to understand. The purpose of this Short Cut is to hit the “sweet spot” that no other works currently do: the right balance between simplicity and useful information.
Programming log4j is simple. Configuring it is what’s hard. Because of that, this Short Cut focuses mostly on how to configure log4j than on the API for using it.
There are a few important concepts that need to be explained a priori in order to provide a context for discussion.
This is the core unit of work in the log4j architecture. Everything that happens after your code issues a log statement (the mechanics of which we’ll see soon enough) is focused on the Log Event: where the Event ends up, how it is formatted or if it is even seen at all. This Short Cut will talk about Log Events a lot, so it’s handy to think of them as a piece of logging information whose origin is your Java code. Unless otherwise noted, log event and event are synonymous and are used to refer to the concept of “something to be logged.”
In conceptual terms, this is the “something” that is to be logged, and is usually a String (but not always) containing a message intended to be read by a human (but not always). The terms log message and message are used synonymously throughout this Short Cut and refer the content of the Event. To put it another way: you create the Message in your Java code. Log4j creates the Event.
This is the importance of a log event, as determined by you, the developer, when you write your code. The Level of an event serves as the default criterion upon which the decision is made by log4j to filter it out or not.
One of the main reasons to use log4j is that it allows you—the developer—at compile time, to specify the importance (Level) of a particular log message (Event), and then determine at some later time—deployment or runtime—whether or not that message gets seen.