This is a valid criticism of the remoting module and one I discussed in depth with Tom Elrod about. In general the remoting module is too monolithic in its view of how to handle invocations and needs to be refactored to allow class loading to be delayed until it reaches the deployment context that is the target of the invocation. At that point the deployment context class loader is in effect and full unmarshalling of the application specific types can be done.

If a transport has to have complete visibility into the types of the invocation, then it is effectively tightly coupled to the deployment context using the transport. This does not fit well into the decoupled remoting framework. It should be possible to associate a particular transport handler with the class loader of the deployment context it is serving requests for, but this cannot be required for all transport layers.

Also need ability to separate the payloads as is done the the current invoker so can include things such as security credentials to server side to check security before allowing dynamic classloading (which would have to be done before deserializing the target payload).

For Remoting 3, a solution to this problem presents itself in that the handler identifier, in other words the Object key that identifies the operation to be performed, can be used to locate the ClassLoader to use to deserialize the request.

Basically Remoting could look at the class name of the identifier, then look up all the registered keys that share that class name, grouped by the ClassLoader of the key. For each ClassLoader, the key is deserialized and checked against the registry - if it is equal, then use the ClassLoader associated with the deployment that registered the key to deserialize the payload and invoke the operation.

It is a bit clunky if the identifier needs to be deserialized more than once - but it is my belief that this will seldom happen, as people will typically use either a JDK class like String for their key (which is available to all ClassLoaders) or a class or enum that is specific to their deployment.