Remoting 3: Transporters

[dmlloyd]

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!

[trustin]

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

[dmlloyd]

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

[dmlloyd]

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.

[dmlloyd]

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?

[trustin]

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