Now you've made the mistake of showing some interest in this :-) Consider this line from the yourkit trace.
"#6666","2:34.164","main","WSDLManagerImpl.loadDefinition","sun.reflect.GeneratedConstructorAccessor65","loaded" Someone has done something reflective that creates a class, and that class sticks around. I suspect that the WSDLFactory is the culprit here. Got any ideas for how to force it into the context class loader? On Sun, Nov 21, 2010 at 10:34 AM, <[email protected]> wrote: > > > On Nov 21, 2010, at 9:43 AM, Benson Margulies <[email protected]> wrote: > >> I see two apparent sinks of permgen in our build from yourkit. >> >> One is the XSD-to-Java mojo, which doesn't belong to us. But we might >> be able to wrap it in such a way as to change its behavior. > > Or just use the cxf-xjc-plugin that we do have control over. > > Dan > > > >> >> The other is the SOAPBindingUtil.getProxy. The proxy classes, which >> co-locate in the class loader of the classes they proxy, never go >> away. >> >> So, they end up in the per-plugin class loader, which isn't going to >> go away for the life of the build. >> >> So, it looks like we need an additional classloader in the path here >> that can be GC'd. >> >> The WSDL2Java mojo is the top of this. >> >> Question: should SOAPBindingUtil just use the thread context class >> loader, which would allow us to easily deal with this in the mojo, >> instead of sticking the proxies into the same class loader as the >> things proxied? >> >> I think so. > >
