[jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Remoting and remote classloading

[ron.sigal@jboss.com]

On porting JBREM-962 "Remote classloading does not work with Isolated EARs" to JBossAS 5 and Remoting 2.4:

"scott.stark at jboss.org" wrote : 
  | 
  | "ron.sigal at jboss.com" wrote : 
  |   | If RemotingClassLoader can't find a class locally, it will try to contact a Connector with a MarshallerLoaderHandler, which will send back a class if it can find it.  For Remoting 2.2 and EAP 4.2/4.3, I made it possible to configure a Connector with the object names of a set of loader repositories (which come from jboss-app.xml files), so that MarshallerLoaderHandler can search for classes in scoped EARs.  At first I thought you were saying that the TCL was a magic bullet I could use in place of external configuring, but I see that that's probably not the case.  So I guess my question is: "Are there equivalent bean names, either for classloaders or repositories, that I can use in place of the JMX object names?".
  |   | 
  | 
  | There are bean names, but the remoting layer should not end up trying to marshall things it does not know about and introduce a dependency on a server specific class loading implementation. The TCL is a magic bullet when the call has passed onto the handler. Outside of that, the remoting layer should not have to deal with class loading.
  | 

Without access to classloaders other than its own, Remoting's remote classloading facility would be crippled, which was the genesis of JBREM-962.  A  user had EJB A and EJB B in two different scoped EARs, and he wanted EJB A to call a method on EJB B that returns an instance of a class that was unavailable to EJB A.  With the fix from JBREM-962, the unmarshaller in EJB A can download the missing class by contacting Remoting's MarshallerLoaderHandler running in a Connector "affiliated" with the EJB3 Connector that serves EJB B.  But that only works if the user configured the EJB3 Connector that serves EJB B with the name of the right classloader repository.

I would argue that in this situation, Remoting's MarshallerLoaderHandler *is* the handler responsible for setting the TCL, though it's outside of the usual channels for mapping applications to classloaders.

I guess the basic question is, do we want to continue to support Remoting's independent remote classloader facility?  Or should Remoting just depend on the Application Server's RMI classloader facility?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169369#4169369

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