I am using several of the other commons components and hibernate that use the commons-logging API to abstract from the underlying log4j or Java Logging APIs.
Unfortunately due to a bug in JDK 1.4 which does not release references to class definitions correctly when commons-logging is containing in a J2EE web application WAR file and the application is redeployed. The only reliable solution is to deploy log4j and the commons-logging and commons-logging-optional (1.0.5-alpha) jar files as shared libraries for the entire J2EE server. That approach has worked well in my development environment. The application is however going to be deployed in a shared server that I have little control over and it is unlikely that I will be able to deploy these libraries as shared components as all the other applications have local log4j config files so it would require a lot of testing and tweaking of other applications to get everything to work correctly. One potential solution I can think for this is to create a clone of commons-logging that just provides the same interfaces but is statically bound to log4j so that it would not have to do all the lookups and caching of class references that goes on right now. This would be a similar thing to slf4j.org (UGLI) but with the existing commons logging interface so it can be dropped in as a replacement for commons-logging for other API's that already use it. Has anyone looked at this or know of any other solutions to the out of memory issues. Cheers, Paul
