Were JIRA's created for these? Are patches available?
Just wanted to make sure this doesn't get lost. Thanks! Dan Daniel Feist wrote: > > No thoughts on this one? I'll go ahead and file JIRA's then with > patches... not sure about test cases though, have to think about to > reproduce/test with unit test. > > Dan > > Begin forwarded message: > >> From: Daniel Feist <[email protected]> >> Date: October 28, 2009 6:15:54 PM GMT-02:00 >> To: [email protected] >> Subject: Classloader leakage when using JAXB binding in appServer >> >> Hi, >> >> I'm experiencing some class-loader leakage with a couple of cxf >> classes and was wondering if anyone had seen this before or had any >> ideas on possible solutions. >> >> Scenario: >> >> - Mule+CXF (all mule libs, all cxf libs and all dependencies) are >> deployed as part of JCA .rar archive in Jboss. (It would be the >> same with other appServers, or if libs are on the server class-path >> or a sar/car etc. is used.) >> - Therefore all CXF classes are loaded by a classloader that is >> parent to webapp classloaders. >> - Endpoints are configured and deployed using webapps, this is using >> Mule but what occurs from the CXF perspective is that a >> ServerFactoryBean, ServerFactory are Service are created and used. >> - Endpoints are undeployed when webapp is undeployed. Cxf Service >> is stopped etc. >> - CXF version 2.1.5 >> >> Issue: >> >> Even though everything that is no longer used gets garbage collected >> without an issue ((Mule) CXFMessageReceiver and well as (CXF) >> ServerFactory, Service etc.) classloader leakage is observed whereby >> a WebappClassloader is created and never destroyed for each redeploy >> of the same webapp! >> >> Probable Causes: >> >> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP >> >> This map continues to have reference to classes generated and used >> by the now undeployed webapp meaning the webapp classloader never >> goes away. >> The implementation of this map although weak is not weak enough, >> because if a entry references a key (it seems to) then the key >> although it is a WeakReference never goes away and therefore neither >> does the entry (the classloader). >> >> See the "implementation note" 2/3 of the way through the javadoc >> here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html >> >> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE >> >> Here is appears we have another map the maintains references to the >> generated classes and in turn to the webappClassloader that is no >> more expect this one doesn't even try to be weak. I notice there is >> a clearCaches() method but i'm unsure about using that at anytime in >> runtime because even though i'm taking down one cxf Service there >> may be user services alive using jaxb at the same time. >> >> I didn't file any jira issue(s) yet because I wanted to push it out >> on the list first and see if there was anything I was missing or if >> this is indeed a real issue. >> >> thank! >> >> Dan >> >> > > -- View this message in context: http://old.nabble.com/Classloader-leakage-when-using-JAXB-binding-in-appServer-tp26101445p26779942.html Sent from the cxf-user mailing list archive at Nabble.com.
