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 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
• Benefits of support for Jakarta Commons Logging
• Overview of the process for using Jakarta Commons Logging
• Classes used to obtain a logger factory and logger
• Logger level configuration and mapping

Support for Jakarta Commons Logging

WAS v8.5 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.

WAS v8.5 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:

• WAS 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 the 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 WAS, 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 not specific to WAS. An application must know what factory is being used in order to configure it.

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

Classes used to obtain a logger factory and logger

Jakarta Commons Logging class descriptions. Use the classes for a logger factory instance 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 WAS, 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 context class loader 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 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 prior to 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 loggers 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. The first column shows the levels defined in Java Logging and the level mapping in the Jakarta Commons Logging JDK14Logger to the Java Logging levels.

Mapping of WsJDK14Logger levels to Java Logging levels. Compare the logging levels.

WsJDK14Logger	Java Logging in WAS	Java Logging	JDK14Logger
Fatal	Fatal
Error	Servere	Servere	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.

Related information:

JSR 47: Logging API Specification

Jakarta Commons

Specification: Common Base Event

Standardize messages with the Common Base Event model

+

Search Tips   |   Advanced Search