Using the Jakarta Commons, Part 3
Pages: 1, 2, 3, 4
Logging
Summary: Wrapper library around a set of popular logging implementations.
Where: Main Page, Binaries, Source.
When: When your application requires more than one logging implementation, or you anticipate such a need in the future.
Example Application: LoggingDemo.java, commons-logging.properties requires commons-logging.jar in the CLASSPATH. Requires log4j.jar, in certain cases.
Description:
Logging enables your applications to debug and trace their behaviors at any
point in time. Logging is an integral part of any application, so there are
many third-party logging implementations that eliminate the need for you to
write your own logging API. In fact, even the JDK comes with a prebuilt logging
API. With such a plethora of choices (log4j, JDK, Logkit, et cetera), the choice
of a particular logging API to use within your own application comes down to
selecting the one that best suits your requirements. However, a case can be
made for instances where the choice of a logging API may not be compatible
within applications, either because of company requirements or incompatibilities
with existing architecture. The idea of the Logging component is to wrap the
requirement of logging within a set of standard APIs where the underlying
implementation can change or differ. The developer simply uses this API to make
the log requests. The API decides, based on available logging architectures, to
direct these logging calls to the appropriate handler. Thus, the Logging
component, as far as the developer is concerned, is independent of any
particular logging implementation.
If you are familiar with using log4j (also see this log4j article), using Commons-Logging should not be a problem. Even if you are not familiar with it, using Commons-Logging requires you to import two classes,
create a static instance of a Log, and log away. The relevant code
bits are shown below:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class LoggingDemo {
private static Log log = LogFactory.getLog(LoggingDemo.class);
// ...
}
An interesting thing happens when you call LogFactory.getLog().
A process of discovery is started to find the required Logging implementation,
according to the following scheme. Note that irrespective of how the desired
implementation is found, it should be a class that implements the
Log interface and is available in the CLASSPATH.
Commons-Logging comes prebuilt with Jdk14Logger,
Log4JLogger, LogKitLogger, NoOpLogger
(which simply swallows all messages), and a SimpleLog.
Commons-Logging looks for a configuration file called commons-logging.properties in the
CLASSPATH. This file must define, at the minimum, the propertyorg.apache.commons.logging.Log, and it should be equal to the fully qualified name of one of the implementations of theLoginterface listed above.If a configuration file cannot be found with the right property above, Commons-Logging looks for a system property called
org.apache.commons.logging.Log.If there is no system property with the above name, Commons-Logging looks for
log4jclasses in theCLASSPATH. By the simple act of finding these classes in theCLASSPATH, Commons-Logging assumes that you are usinglog4j. However, note thatlog4jstill needs to be configured for its properties in its own log4j.properties file.If none of the above is found and if the application is running on JRE 1.4 and above, the application defaults to using the JRE1.4's logging mechanism.
Finally, if none of the above is valid and the application is not running on JRE 1.4 and above, the application uses a built-in
SimpleLog, which writes everything toSystem.err.
Once the desired logging implementation has been obtained, you can start logging within your environment, based on your rules and degree of severity of your log messages. Using a standard API abstracts from the underlying mechanism and the same call is translated into implementation-specific calls.
|
Related Reading Jakarta Struts Pocket Reference |
The supplied demo file simply prints an information message and tells you
which logging implementation was used to do so. Try running this file in different
environments, for example, run the file on its own without specifying any
properties, and you will default to Jdk14Logger. Run it by specifying the system
property as -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog,
and you will see that SimpleLog is used to print the message.
Finally, try putting Log4 classes in the CLASSPATH. If you have
set the correct configuration for log4j in a log4j.properties
file, you will get the message created with Log4JLogger.
