Hi Simon, I think adding the following ContextListener solved the problem.
http://static.springframework.org/spring/docs/1.1.5/api/org/springframework/web/util/IntrospectorCleanupListener.html Paul On Tue, 2005-07-26 at 08:09 -0700, Paul Austin wrote: > Hi Simon, > > I am running my application on Tomcat 5.5 under Sun JDK 1.4.2_07-b05 on > Windows XP. For the production environment it will be Oracle Application > Server 9.0.4.1 under JDK 1.4.2 on Solaris 2.8 (I haven't had access to > test on that server yet). > > The original discussion where I started to find out about the problem > was on the hibernate forums. > > http://forum.hibernate.org/viewtopic.php?t=935948&highlight=permgen > > One of the things I tried was adding a context listener which had the > LogFactory.release method called. There are also 3 filters which use > springframework/hibernate which use libraries that may use > commons-logging. I'm guessing that perhaps the destroy method on the > filters is called after I call LogFactory.release thus some new log > instances are created thus undoing the work in the release method. > > I'll try to get a stripped down copy of the application that still has > the issue put together to help solve this problem. Won't be this week as > I have to deliver the application. > > Cheers, > Paul > > On Tue, 2005-07-26 at 16:58 +1200, Simon Kitching wrote: > > > Hi Paul, > > > > On Mon, 2005-07-25 at 12:25 -0700, Paul Austin wrote: > > > 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. > > > > I'm not sure what "bug in JDK 1.4" you're referring to. Do you have any > > further info on this? > > > > If commons-logging is deployed via a shared classloader and the servlet > > engine is not commons-logging-aware then components such as webapps need > > to ensure that LogFactory.release is called when they are undeployed in > > order to avoid exactly the situation you describe. Note that Tomcat is > > "commons-logging-aware" and does this automatically. This isn't a "bug", > > it's a known cleanup step. The commons-logging-optional.jar does > > *sometimes* remove the need for the call to LogFactory.release but not > > always which is why I prefer to use LogFactory.release instead of or as > > well as the optional jar. > > > > I don't know of any situations where such a memory leak is *caused* by > > having commons-logging in the component's WEB-INF/lib. More information > > would be welcome. > > > > What container (eg tomcat, jboss) are you using? > > > > > > > > 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. > > > > Yep, that's the problem of putting libs in a "shared" classloader. It's > > an approach I don't like at all for exactly that reason. > > > > > > > > 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. > > > > Yep, adopting some of the ideas from UGLI is something that has been > > looked at. There are some definite benefits, but also some disadvantages > > to this approach. Some prototyping of this has been done but nothing > > that is likely to be released this year. > > > > > > > Has anyone looked at this or know of any other solutions to the out of > > > memory issues. > > > > If you can provide more information I would be willing to help you look > > into this. I don't see any reason why the current commons-logging > > wouldn't work for you provided things are set up correctly. > > > > Regards, > > > > Simon > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > >
