ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

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.

  1. Commons-Logging looks for a configuration file called commons-logging.properties in the CLASSPATH. This file must define, at the minimum, the property org.apache.commons.logging.Log, and it should be equal to the fully qualified name of one of the implementations of the Log interface listed above.

  2. 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.

  3. If there is no system property with the above name, Commons-Logging looks for log4j classes in the CLASSPATH. By the simple act of finding these classes in the CLASSPATH, Commons-Logging assumes that you are using log4j. However, note that log4j still needs to be configured for its properties in its own log4j.properties file.

  4. 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.

  5. 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 to System.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.

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.

Pages: 1, 2, 3, 4

Next Pagearrow