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.