Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy)
To: bimargulies@gmail.com
Cc: dev@cxf.apache.org
Subject: Re: Permgen, permgen
Content-transfer-encoding: 7bit
From: dkulp@apache.org
Content-type: text/plain; charset="utf-8"
Message-id: <72573857-4806-4872-976E-66C177689B09@apache.org>
Date: Sun, 21 Nov 2010 10:34:53 -0500
Mime-version: 1.0 (iPhone Mail 8A306)


On Nov 21, 2010, at 9:43 AM, Benson Margulies <bimargulies@gmail.com> 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.