"scott.stark(a)jboss.org" wrote : I have been talking to Ron about some current remoting class loading issues that arise from the invocation handler being the only one who knows the correct class loader for unmarshalling application specific classes: | | 1. thread pool receives a remoting request. | 2. unmarshall just enough to understand the request, but don't unmarshall any invocation payload. Application specific data needs to be isolated outside of the remoting control structures to allow this to happen. | 3. dispatch the request to a handler. | 4. handler sets the TCL | 5. handler or its delegate unmarshalls application payload | 6. application does what is does. | 7. handler serializes application return/exception and then unsets the TCL | 8. remoting layer completes request control information | So the core of this issue is that Remoting 2 mixes control objects in with the invocation payload in the wire protocol. Or put more generally, a request may be comprised of objects that have to be unmarshalled by different classloaders, where the proper classloader may not be evident based on the current unmarshalling state. (Let me know if I'm not understanding something...) In R3 this is solved in part because there's no Remoting control data in the request itself. So as long as you keep your requests confined to a single classloader (on the receiving side) then things should work out. I think that associating a service with its appropriate classloader would be the right thing to do there (the protocol handler would then choose the classloader based on the service being invoked). Given the R3 design, which makes requests and client instances much more lightweight, mixing classloaders in requests would be an indication of improper service design - if you're doing that, you probably need multiple services (one for each aspect that lives in its own classloader). (Deliberately not yet broaching the topic of R3's remote classloading system) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169178#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...