[jboss-dev-forums] [Design of EJB 3.0] - Re: Classloading problem in proxy factories

[ALRubinger]

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#4172733

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172733