1 Reply Latest reply on Dec 23, 2004 9:17 AM by tom.elrod

    request payload

    mazz

      Let me know if my understanding of this is incorrect.

      Reading "JBoss Remoting Version 1.0.1 alpha" doc (dated Nov 15, 2004) I see this:

      "Then we make our invocation, passing 'Do something' as our parameter [to Client.invoke]. The second parameter is null and is only used to specify protocol specific hints".


      So, I am assuming that request payload parameter should not really be used to pass client payload data for the actual operation to be invoked (analogous to method parameters in a normal Java call) - rather, that data should be encoded in the parameter object (that first argument). In other words, the first argument to that invoke should encapsulate both the operation to perform (think "method name") and the operation parameters (think "method arguments").

      The docs don't really get into that request payload data - what is it used for?

        • 1. Remoting and ClassLoader domains don't mix

          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