"ron.sigal(a)jboss.com" wrote : | 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. | This is a form of rmi remote class loading, but that is simply a feature, not a crippling issue in my view. In general that usage is not possible because if the caller does have a class from ejb B that conflicts with it due to a local version difference, it has to be marshalled into the class loader space of ejb A. "ron.sigal(a)jboss.com" wrote : | 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? I'm not saying we should not have a remote class loading feature to pull classes across the wire. I'm saying that its a pure delegation facility that requires the actual class loader to be provided to the remoting layer. A potential problem I see with the MarshallerLoaderHandler is that is calling the ServerInvoker for a class loader. A protocol specific handler is not going to know how to get class loaders for all of the invocation targets in use. Ejb3 is complete different from ejb2. "ron.sigal(a)jboss.com" wrote : | I guess injecting a list of classloaders would be pretty general. | Yes, if we can have an application level bean register its class loader with the remoting layer to enable remote class loading, that is what we want. This would also allow the application layer to wrap its class loader in a filtered class loader with a policy that restricts what content can actually be remoted. Registering a class loader with remoting should be a priviledged operation with a security check to ensure only application framework code can perform the registration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169390#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...