"david.lloyd(a)jboss.com" wrote : | 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. | No, I mean if the response object container the unmarshalled object that is going to be streamed by the transport layer after the handler has cleared the TCL, possibly in another thread. "david.lloyd(a)jboss.com" wrote : | 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. The TCL only works for class loading that occurs in the scope of a request dispatch. The concern is for marshalling that occurs after the handler has returned, and cleared the TCL. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169311#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...