5 Replies Latest reply on Nov 21, 2008 3:35 AM by Trustin Lee

    Remoting 3: Transporters

    David Lloyd Master

      Not sure if you guys noticed, but the other night I whipped up a Transporter implementation and put it in, thinking back to Ron's comment about how he hopes they stay around.

      Let me know what you think!

        • 1. Re: Remoting 3: Transporters
          Trustin Lee Apprentice

          A couple findings:

          1) TransporterInvocation.readExternal(...) doesn't update the member variables but only the local final ones.

          2) TransporterInvocation.writeExternal(...) checks if the length values of parameterTypes and args are same, but I think this code should be moved to readExternal(...).

          Except the above, it looks very good to me. :)

          • 2. Re: Remoting 3: Transporters
            David Lloyd Master

             

            "trustin" wrote:
            A couple findings:

            1) TransporterInvocation.readExternal(...) doesn't update the member variables but only the local final ones.


            Yup, that's a bug. Fixing now...

            "trustin" wrote:
            2) TransporterInvocation.writeExternal(...) checks if the length values of parameterTypes and args are same, but I think this code should be moved to readExternal(...).


            This is intentional. Only one length is written for both arrays, so it's checked on the write side. On the read side, they cannot differ since only one length is read.

            • 3. Re: Remoting 3: Transporters
              David Lloyd Master

              BTW, it's OK to create JIRA issues for these problems. Just make sure you select one of the "r3 *" components as well as marking the "fix for" version to Beta2.

              • 4. Re: Remoting 3: Transporters
                David Lloyd Master

                I've been thinking more about the implementation of Transporters. Right now they can only be created locally and sent as part of a request - there's no notion of a registry for example. It wouldn't be too great of a stretch to add a transporter service, which would return remote references upon request.

                Of course at that point we could take it one step further, and create a complete alternate RMI implementation based on our marshalling mechanism...

                What do you guys think? Something to consider for 3.1 or 3.2?

                • 5. Re: Remoting 3: Transporters
                  Trustin Lee Apprentice

                  I like the idea. I'm curious how your idea would relate to the remote VFS.