On Wed, 2005-08-10 at 19:25 +1200, Simon Kitching wrote: > Hi Paul, > > Try the following URL, select "view" on the latest file and search for > Introspector. Then try walking back through the versions until you find > a version that doesn't have the fix. It looks like 1.46 is the relevant > patch, so Version 5.0.28 doesn't have it, but 5.5.8 does. > > http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java?only_with_tag= > > Cheers, > > Simon > > On Mon, 2005-08-08 at 10:35 -0700, Paul Austin wrote: > > Hi Simon, > > > > You mention that Tomcat 5.5 flushes both the Introspector cache and > > does the Commons Logging cleanup to. Which version of 5.5 was this > > introduced as I have been running with Tomcat 5.5 and had the problems > > until I used the solution I mentioned below. > > > > Paul > > > > On Sat, 2005-08-06 at 11:03 +1200, Simon Kitching wrote: > > > [AARGH- I hate top-posting!] > > > > > > Thanks for the info Paul. The point about flushing the Introspector > > > cache is a good one. I've added some info to the wiki about this. Note, > > > however, that commons-logging doesn't use any bean introspection itself. > > > > > > In the case of Tomcat 5.5, tomcat already explicitly flushes the > > > introspector caches on webapp undeploy so code running in that container > > > shouldn't be hit by this JDK problem. > > > > > > I don't know much about spring; it might well need this to be done > > > manually. > > > > > > Regards, > > > > > > Simon > > > > > > On Fri, 2005-08-05 at 11:36 -0700, Paul Austin wrote: > > > > 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] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
