Configurations for the WAS logger
This page describes several ways to configure an application to use the WAS logger.
The type of configuration that best suits an application depends upon the following:
- Whether the Class loader order setting for the application is Classes loaded with parent class loader first (Parent First) or Classes loaded with application class loader first (Parent Last). We can set the class loader delegation mode on a console Class loading and update detection page.
- Whether Jakarta Commons Logging is bundled with the application configuration
- Whether Jakarta Commons Logging is provided within the application
The following tables describe the conditions required to enable an application to use the WAS logger.
Class loader mode is Parent First and Jakarta Commons Logging is bundled with the application
Jakarta Commons Logging configuration LogFactory instance Log instance Comments The application provides the configuration by either of the following: • The properties file commons-logging.properties in the application classpath is not read by the LogFactory because the parent class loader finds the WebSphere properties file first. • The class name is read from the file
META-INF/services/ org.apache.commons .logging.LogFactoryThe log factory used is the LogFactory implementation specified in the WAS default configuration, unless the configuration is provided in a META-INF file of the application or module. The log used is either of the following: • The Log implementation specified in the WAS default configuration
• An application-specific Log implementation if an application-specific LogFactory that instantiates a different Log implementation is used.
The application parent class loader is the first class loader to load the Jakarta Commons Logging code. The WebSphere bundle that supports Jakarta Commons Logging provides the LogFactory static code that looks up the LogFactory configuration attributes. For the static LogFactory code to instantiate the LogFactory instance specified in the application configuration, the LogFactory instance must be on the classpath of the parent class loader.
Not provided by the application The log factory used is the LogFactory implementation specified in the WebSphere default configuration. The log used is the Log implementation specified in the WebSphere default configuration. The Jakarta Commons Logging bundled with the application is not used.
Class loader mode is Parent First and Jakarta Commons Logging is not bundled with the application
Jakarta Commons Logging configuration LogFactory instance Log instance Comments The application provides the configuration by either of the following: • The properties file commons-logging.properties in the application classpath is not read by the LogFactory because the parent class loader finds the WAS properties file first. • The class name is read from the file
META-INF/services/ org.apache.commons .logging.LogFactoryThe log factory used is the LogFactory implementation specified in the WAS default configuration, unless the configuration is provided in a META-INF file of the application or module. The log used is either of the following: • The Log implementation specified in the WAS default configuration
• An application-specific Log implementation if an application-specific LogFactory that instantiates a different Log implementation is used.
The application parent class loader is the first class loader to load the Jakarta Commons Logging code. The WebSphere bundle that supports Jakarta Commons Logging provides the LogFactory static code that looks up the LogFactory configuration attributes. For the static LogFactory code to instantiate the LogFactory instance specified in the application configuration, the LogFactory instance must be on the classpath of the parent class loader.
Not provided by the application The log factory used is the LogFactory implementation specified in the WAS default configuration. The log used is the Log implementation specified in the WAS default configuration. Same as in the previous row
Class loader mode is Parent Last and Jakarta Commons Logging is bundled with the application
Jakarta Commons Logging configuration LogFactory instance Log instance Comments The application provides the configuration by either of the following: • The properties file commons-logging.properties in the application classpath is read by the LogFactory because the class loader finds the application properties file first. • The class name is read from the file
META-INF/services/ org.apache.commons .logging.LogFactoryThe log factory used is either of the following: • The default Jakarta Commons Logging LogFactory
• The LogFactory specified in the application configuration
The log used is the Log implementation specified in the application configuration. If the log factory used is the default Jakarta Commons Logging LogFactory, the Log implementation must be on the classpath of the application class loader.
The application class loader is the first class loader to load the Jakarta Commons Logging code. The application bundle that supports Jakarta Commons Logging provides the LogFactory static code that looks up the LogFactory configuration attributes. For the static LogFactory code to instantiate the LogFactory instance specified in the application configuration, the LogFactory instance must be on the classpath of the application class loader.
Not provided by the application The log factory used is the LogFactory implementation specified in the WAS default configuration. The log used is the Log implementation specified in the WAS default configuration.
Class loader mode is Parent Last and Jakarta Commons Logging is not bundled with the application
Jakarta Commons Logging configuration LogFactory instance Log instance Comments The application provides the configuration by either of the following: • The properties file commons-logging.properties in the application classpath is read by the LogFactory because the class loader finds the application properties file first. • The class name is read from the file
META-INF/services/ org.apache.commons .logging.LogFactoryThe log factory used is either of the following: • The default Jakarta Commons Logging LogFactory
• The LogFactory specified in the application configuration
The log used is the Log implementation specified in the application configuration. If the log factory used is the default Jakarta Commons Logging LogFactory, the Log implementation must be on the classpath of the application class loader.
There is no Jakarta Commons Logging code at the application class loader. Thus, the WebSphere bundle that supports Jakarta Commons Logging provides the LogFactory static code that looks up the LogFactory configuration attributes. For the static LogFactory code to instantiate the LogFactory instance specified in the application configuration, the LogFactory instance must be on the classpath of the parent class loader.
Not provided by the application The log factory used is the LogFactory implementation specified in the WAS default configuration. The log used is the Log implementation specified in the WAS default configuration.
 
Related concepts
Class loaders
Related tasks
Set applications to use Jakarta Commons Logging 
Related information
JSR 47: Logging API Specification
Jakarta Commons
Logging/Containers And Classloaders