September 28, 2005
A different implementation for commons-logging

Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.  It is also one of the not-so-good APIs or implementations.

The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.

An alternative - that will work better in most cases - is to write a specific commons-logging implementation for  each  backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.

The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for political reasons.

For minimal tomcat,  I  wrote a simple commons-logging implementation based on the simple 'System.err' example, but with support for a subset of log4j.properties. This way it is quite easy to switch to full log4j, but you can still use the lower footprint implementation - just a wrapper on top of System.err, with ability to filter based on level. I also have ( almost complete ) implementations of commons-logging specific to log4j and JSR-logging.

This will take away the pain and risks of discovery, reduce the code size, with the only downsize that you need to choose a logging implementation by deploying the jars for the logger and the commons-logging. You already have to do the first part anyway.

With this - I am quite happy with commons-logging. The only thing I really don't like is the use of interfaces instead of abstract classes, which removes the ability to do a nice footprint optimization.  If commons-logging ( maybe a 2.0 or alternative ) would use classes, it would be possible to have a 'no debug' implementation, where all debug() and trace() are final void methods. Most compilers would deal with this by compiling out all the debug statements - reducing the size of the binary. It is possible to do this currently, by replacing the interface with the class - but this is not backward compatible, you can't replace an interface with a class. I have been playing with this for a while, not sure what to do about it - maybe release it under a different name ( to avoid confusion with commons-logging, since it's incompatible ).

Posted by costin at September 28, 2005 11:18 PM
Comments
Disabled due to spam. Click on the link to post a comment, it'll be sent in email ( and thus usual mail spam filters and blacklist applied ). It may be made accessible later on, but code needs to be written for that. Comments