Jakarta Commons Logging

Jakarta Commons Logging provides a simple logging interface and thin wrappers for several logging systems. The logging interface enables application logging to be simple and independent of the logging system that the application uses. We can change the logging implementation for a deployed application without having to change the application logging code. However, the simplicity of the logging interface prevents the application from leveraging all the functionality of the logging systems.

This topic provides the following information about Jakarta Commons Logging in WebSphere Application Server:

Support for Jakarta Commons Logging

WebSphere Application Server supports Jakarta Commons Logging by providing a logger, a thin wrapper for the WAS logging facility. The logger can handle both Java Logging (JSR-47) and Common Base Event logging objects. A logging object is an object that holds logging entry information.

The WAS support for Jakarta Commons Logging does not change interfaces defined by Jakarta Commons Logging.

Benefits of support for Jakarta Commons Logging

The WAS support for Jakarta Commons Logging provides the following benefits:

  • WebSphere Application Server is pre-configured to use Jakarta Commons Logging.

    All of the functionality of Jakarta Commons Logging is provided for any application or WAS component. Logging calls are routed by default to the underlying WAS logging facility.

  • A logger that uses the WAS logging facility.

    Applications and components can pass both Java Logging and Common Base Event logging objects to the WAS logger without conversion to strings, providing applications with enhanced logging. Further, Jakarta Commons Logging Logger levels are integrated into WAS administrative facilities.

Overview of the process for using Jakarta Commons Logging

Logging with Jakarta Commons Logging consists of the steps that follow. Configurations for the WAS logger provides details on configuring your application to use the WAS logger.

  1. Obtain an instance of a logger factory.

    To obtain a logger factory, use Jakarta Commons Logging code. We can configure the code to meet your needs. In WebSphere Application Server, Jakarta Commons Logging is configured by default to instantiate the Jakarta Commons Logging default logger factory. Applications or WAS components can provide their own configuration if they use a different logger factory implementation. Applications can use more than one factory.

  2. Obtain an instance of a logger.

    To obtain a logger, use code implemented by a logger factory. Configuration of the code is implementation specific.

    The WAS logger implements the methods defined in the logging interface. The logging methods take at least one argument, which can be any Java object. The WAS logger, the WsJDK14Logger logger described in Classes used to obtain a logger factory and logger, handles the following objects passed into the following logging methods:

    CommonBaseEvent
    Wrapped into CommonBaseEventLogRecord
    CommonBaseEventLogRecord
    Passed without change
    LogRecord
    Passed without change
    Other objects
    Converted to String

    Applications or WAS components can provide their own configuration if they use an implementation of a logger that is not specific to WebSphere Application Server. An application must know what factory is being used in order to configure it.

  3. Start your application. Jakarta Commons Logging routes the application's logging output to the designated logger

Classes used to obtain a logger factory and logger

Class name Description
LogFactory LogFactory is a Jakarta Commons Logging class that implements initialization logic. LogFactory is an abstract class that every logger factory implementation has to extend. It provides static methods for obtaining:
  • An instance of a factory class
  • Instances of a logger, using an instance of the factory class
LogFactory provides methods for obtaining instances of loggers, although these methods delegate the logger instantiation and configuration to an instance of a logger factory class.

Logger factories, once instantiated, are cached on a per context class loader basis. The instances in a cache can be released. This functionality is designed for platform container implementations rather than for applications.

LogFactoryImpl LogFactoryImpl is a Jakarta Commons Logging concrete class that implements the default logger factory using methods in LogFactory. To use Java Logging, there must always be at least one instance of a logger factory class, even if the application has not explicitly obtained one. If the configuration does not name a logger factory class, LogFactoryImpl is used as the default.
Log Log is a Jakarta Commons Logging interface for loggers. Commons logging loggers have to implement the Log interface. Because the goal of Jakarta Commons Logging is to wrapper any logging system, the Log interface defines a small set of common logging methods. In WebSphere Application Server, WsJDK14Logger implements the Log interface.

Logger instantiation and configuration is specific to every logger factory. Logging in WAS uses the default logger factory provided in Jakarta Commons Logging, which keeps instantiated loggers in cache, on a per class loader context basis.

WsJDK14Logger WsJDK14Logger is a WAS class that provides a Jakarta Commons Logging logger by implementing the Log interface. The WsJDK14Logger logger differs from the Java Logging logger in that the WsJDK14Logger logger enables Java Logging or Common Base Event objects to be passed over without converting them into String objects. This prevents any information loss the conversion to String might cause as well as allows the logging output to be more descriptive and precise. In contrast, the Java Logginglogger provided in Jakarta Commons Logging converts objects passed into the logging calls to String objects before passing them over to the underlying Java Logging.

Logger level configuration and mapping

Because Jakarta Commons Logging loggers are thin wrappers for specific logging systems, the loggers do not have their own level, but use the level of the logger from the underlying logging system. Although the underlying system can provide methods for changing level, there are no methods for changing level defined on the Log interface, which all Jakarta Commons Logging logger must implement. WsJDK14Logger uses the level of its underlying Java Logging logger.

Following table shows, on the left, the mapping of Jakarta Commons Logging levels within WsJDK14Logger to levels in the WAS implementation of Java Logging. On the right, it shows the levels defined in Java Logging and the level mapping in the Jakarta Commons Logging JDK14Logger to the Java Logging levels.

WsJDK14Logger Java Logging in WebSphere Application Server Java Logging JDK14Logger
Fatal Fatal    
Error Severe Severe Fatal, Error
Warning Warning Warning Warning
  Audit    
Info Info Info Info
  Config Config  
  Detail    
Debug Fine Fine Debug
  Finer Finer  
Trace Finest Finest Trace

The WsJDK14Logger level is synchronized with the underlying Java Logging logger level. WAS administration controls the WsJDK14Logger level.