I read code in surefire and compiler. Plenty to read, nothing to reuse. This is a bit big for me to tee off on right now, so I'm going to see if there are any other takers before I try.
On Mon, Nov 22, 2010 at 11:07 AM, Daniel Kulp <[email protected]> wrote: > On Sunday 21 November 2010 12:10:37 pm Benson Margulies wrote: >> So, there's a question of approach here. >> >> The general situation I find is this: maven creates a class loader per >> plugin. it hangs onto that for the life of the build. Any class that >> the plugin touches ends up in there, essentially strongly references. >> So anything referenced strongly in, say, a static of one of those >> classes, or anything held in a weak map keyed by that class loader, is >> not going anywhere. >> >> The xsd-to-java mojo that we own can sure drag in a lot of classes, as >> well as some proxies and generated classes from reflection. >> >> All things considered, I think it needs a forkMode. It's possible that >> the wsdl2java mojo should get the same treatment. Without a forkMode, >> what we're faced with is some rather elaborate attempt to subvert >> maven's preference to keeping the class graph of a plugin around for >> the entire build. By the time we've run the testutils build, well, >> we've eaten a whole lot-o-permgen this way. > > Yea. We definitely could use a fork mode. Right now, we cannot really test > the jaxws 2.2 stuff as that would require a fork mode with some way of setting > endorsed things. It also makes it much harder for our USERS to use the maven > plugins to do jaxws 2.2 things. > > Thus, +1 for a fork mode. I wonder if surefire has some code in there to > use as an example. > > Dan > > > > >> >> Thoughts? >> >> 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. > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
