commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Austin <>
Subject [logging] lon4j only implementation to solve out of memory errors
Date Mon, 25 Jul 2005 19:25:54 GMT
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

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

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 (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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message