Network Deployment (Distributed operating systems), v8.0 > Troubleshoot and support > Add logging and tracing to the application > Configure applications to use Jakarta Commons Logging
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 WAS:
- 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
The product 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 product 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
Log 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.
- 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.
- 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 WAS. An application must know what factory is being used in order to configure it.
- 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 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 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. 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.
Mapping of WsJDK14Logger levels to Java Logging levels. Compare the logging levels.
WsJDK14Logger Java Logging in WAS 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.
Configure applications to use Jakarta Commons Logging
JSR 47: Logging API Specification
Jakarta Commons
Specification: Common Base Event
Standardize messages with the Common Base Event model