To explain the reason that TCL code is in place... Without it, when performing web injection (which, by servlet spec, uses an isolated CL), we get: java.lang.IllegalArgumentException: failed to set value Proxy to jboss.j2ee:ear=tx_stateful_web.ear,jar=tx_stateful_web_ejb.jar,name=StatefulTestBean,service=EJB3 implementing [interface org.jboss.ejb3.proxy.intf.StatefulSessionProxy, interface org.jboss.ejb3.proxy.intf.SessionProxy, interface org.jboss.ejb3.proxy.intf.EjbProxy, interface somepackage.RemoteIF] on field private somepackage.RemoteIFsomepackage.TxServlet.remoteBean So even though "somepackage.RemoteIF" is implemented by the Proxy, it clashes with the destination target because the CLs are not equal. "bstansberry" wrote : Seems like generating a Proxy class using something other than the container classloader is a classloader leak. The interface target in a Servlet has a different CL than that of the Container, hence the different CL. "bstansberry" wrote : Perhaps this is a sign of a classloader leak? Proxy.getProxyClass(...) is maintaining a cache of proxy classes I'm not sure this is true, if I'm reading the source and comments from Proxy.getProxyClass correctly: /* | * Note that we need not worry about reaping the cache for | * entries with cleared weak references because if a proxy class | * has been garbage collected, its class loader will have been | * garbage collected as well, so the entire cache will be reaped | * from the loaderToCache map. | */ To move forward, how about we also catch and ignore the LinkageError (to get the proxy-clustered tests passing), and I'll have to proceed with EJBTHREE-1442 to see if this is indeed the source of a CL leak. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172733#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...