"scott.stark(a)jboss.org" wrote : "david.lloyd(a)jboss.com" wrote : 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). | | | Agreed, the target of the remoting invocation should have a distinct class loader that would be set as the request TCL. However, if there is a lazy or streaming facility that allows the marshalling to occur at the remoting layer and there is object replacement via replaceObject, proxy replacement, etc., the marshaller needs the handler TCL saved for the duration of the response. Is there a way the handler can associate that with the response object? | You mean so that the client can pick the right classloader to unmarshal the response? I think that clients should also be associated with a CL as well (anyway we need to do that to allow us to specify a RemoteClassLoader on the client side). I doubt there is likely to be a 1:1 correspondence between classloaders on the client and server side, so I don't really see the benefit of annotating the response with classloader information.ju Setting the TCL for the duration of any task that handles a request is doable though. There are currently no plans to implement any form of lazy unmarshalling. We will need to ensure that the streaming facility can have access to the marshaller as well as the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169298#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...