--kevan
On 10/21/05, Chris Nokleberg <[EMAIL PROTECTED]> wrote:
On Thu, 20 Oct 2005 15:08:05 -0700, David Jencks wrote:
> I spent a couple minutes looking at cglib source code and it looked to
> me as if they were making some effort to cache enhanced classes. I
> would start by trying to figure out why this isn't working for us.
> AbstractClassGenerator.create(Object key) line 199 looks like it's key.
CGLIB uses a key constructed of all the arguments passed to Enhancer that
could affect the bytecode of the generated class.
This is the code in org.openejb.client.CgLibProxyFactory:
private Enhancer getEnhancer(Class superClass, Class[] interfaces) {
Enhancer enhancer;
enhancer = new Enhancer();
enhancer.setSuperclass (superClass);
enhancer.setInterfaces(interfaces);
enhancer.setCallbackFilter(new NoOverrideCallbackFilter(superClass));
enhancer.setCallbackTypes(new Class[]{NoOp.class, MethodInterceptor.class });
enhancer.setUseFactory(false);
return enhancer;
}
The NoOverrideCallbackFilter class does not implement equals/hashCode, so
using a new instance of it for each Enhancer will force generation of a
new class. Because superClass is already part of the key (via
setSuperclass) even something this simple should work:
public int hashCode() { return 0; }
public boolean equals(Object o) { return true; }
The memory fixes that Dain alluded to were eliminating some unintentional
references to old classloaders that would prevent them from getting
GC'ed. I don't think they would affect Geronimo but I recommend upgrading
anyway.
Chris
