"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint Exupery (French Poet, 1900-1940)

If you've done any work at all in server-side Java applications development, you've had some exposure to Jakarta Commons Logging, and one or more of the products that it supports such as Log4j or Java's own native logging facilities that were introduced with version 1.4.

If you have ever tried to use these services in the WebSphere Application Server environment, you have probably already discovered that the default logging implementation does return an instance of Log4j or any other commonly used logging facility.

In a WebSphere Application Server, the standard LogFactory.getFactory()method returns an instance of com.ibm.ws.commons.logging.TrLogFactory and the standard LogFactory.getLog() method returns an instance of com.ibm.ws.commons.logging.TrLog. If you want to use Log4j, you need to do a little extra work.

Overriding IBM Trace Logging
If you want to override the default log implementations in WebSphere, IBM provides an excellent document explaining the various steps necessary to accomplish this. Integrating Jakarta Commons Logging with IBM WebSphere Application Server V5 can be found on IBM's web site at http://www-1.ibm.com/support/docview.wss?uid=swg27004610.

It lays out the various methods that can be employed to implement alternative logging mechanisms, and also reviews those methods that are not recommended. However, before you go to all of the trouble involved in overriding IBM's own logging implementation, you might first consider the value of simply using the default services that they have provided.

Features of IBM's Trace Logging facilities
Most log implementations provide five standard levels of log messages: DEBUG, INFO, WARN, ERROR, and FATAL. IBM's TrLog supports all five of these standard levels, plus adds an additional level called TRACE. Trace-level messages are one notch below debug-level messages; if you set your logging level to DEBUG, the trace-level messages will not appear in your log. The trace-level messages simply provide one more level of logging for sophisticated problem resolution.

Control of the trace-level messages through TrLog is provided through the WebSphere Administrative Console. Unlike Log4j and other log implementations that use a configuration/properties file to set logging configuration parameters, TrLog responds to manipulations directly from the console. Console operators can modify the logging levels for various logs using the facilities built into the administrative console.