3 Replies Latest reply on Aug 9, 2007 10:56 AM by dmlloyd

    Remoting and ClassLoader domains don't mix

    bill.burke

      JBoss Remoting unmarshalls the entire request before it dispatches the request. A big problem with this is when you are dispatching to a different, non-default, classloader domain in that the parameter classes may not be available during demarshalling and class not found exceptions (or CCE when the dispatch actually gets to the target object) will happen. My bet is that our IIOP layer right now has this problem as well.

      The solution would be to not demarshall the method arguments and have invocation.getArguments do a callback to the remoting layer for a demarshall. I don't think this is possible to implement for any IIOP solution or any solution that automatically unmarshalls the buffer.

      Maybe I am missing something, but these class loading boundaries are a real flaw in the whole Invoker architecture.

      Bill

        • 1. Re: Remoting and ClassLoader domains don't mix
          starksm64

          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.

          • 2. Re: Remoting and ClassLoader domains don't mix

            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).

            • 3. Re: Remoting and ClassLoader domains don't mix
              dmlloyd

              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.