| Log4j is an incredibly well designed and functional logging tool. I caught the religion last summer and
with every project I work on, most everyone agrees it's a must know/have tool. Previously I was using
another Java logging library developed internally within my company which I liked. I had no desire to
learn another but did so for the sake of due diligence. Log4j has the following features which set it
apart from others I have seen.
Highly configurable - the ability to configure the properties of your loggers (called Categories in
log4j) from within a property file is indispensible. This allows you to change the characteristics of
your logging without changing code. You can change the logging level, the format of the output and
the output targets very easily. One can also use XML files (though I haven't).
Unobtrusive - I'm finishing a project where we started using another logging tool. The log statements
were clumsily long and required using predefined constants that were hard to remember. When writing
the initial code, "System.out.println" was so much easier to type that people did this for tracing with the
best of intentions to place legitimate logging in later. You know the story. It never happened. Log4j
statements are shorter than "System.out.println" statements. This encourages people to actually use it
rather than simply agreeing to.
Easy configuration - With just one statement, log4j will configure itself with a set of defaults that are useful
until you get around to actually writing your property file, XML file or whatever. Like the point just made before,
this allows log4j to be used at the outset of coding rather than having to wait because you haven't considered
how you wish logging to be configured. The application code itself does not have to know how logging will be
configured.
Performance Concerns - Since Java does not use pre-processor macros, most Java tracing is always
compiled into the code. That means that the decision to compile is made at runtime. There are times when
performance is so paramount that even checking whether to log is a concern. There are other extremes where
other delays make this insignificant so that the performance is easily sacrificed for the increased amount of
information logged (such as method name, class name and line number in source code). The log4j javadoc
documentation explains which information elements are quickly logged and which may compromise performance.
It also includes benchmarks that demonstrate how fast certain statements are logged for a few sample machine
configurations.
Hierarchical Categories - This is highly useful in component based development. Each component has its
own set of logging categories. When individually tested, the properties of these categories may be set however
the developer wishes. When combined with other components, the categories inherit the properties determined
by the integrator of the components. One can selectively elevate logging priorities on one
component without affecting the other components. This is useful when you need a detailed trace from just a
single component without crowding the trace file with messages from other components. All this can be done
with property files - no change in the code is required.
Easily specified output format - Some Java and OO purist disagree with me on this, but allowing one to use
printf-style output format specification is powerful, convenient and compact. Log4j provides a Layout class with
this capability. Of course, for those who wish, you may implement the Layout interface yourself with something
"more OO". Naturally, the printf-style pattern can be specified in a property file.
Customization - Like other loggers, log4j is interface-based making it possible to extend. Log4j supplies
useful implementations that are extended easily without having to implement the interface from scratch.
| 
