8016036: RMI specification needs to be updated to allow Activation on remote hosts
stuart.marks at oracle.com
Tue Jul 30 20:00:10 UTC 2013
On 7/29/13 7:48 AM, Alan Bateman wrote:
> On 29/07/2013 07:12, Bob Vandette wrote:
>> Excuse me if I'm a bit frustrated by this issue ...
>> We keep going around and around on this issue. We had a discussion with
>> Stuart and the JCK
>> team and Stuart didn't want to change the specification. Has he now changed
>> his mind?
>> Security and configuration issues aside, I don't understand why it doesn't
>> make sense to remote
>> activate an Object in an API that is supposed implement "Remote Method
>> Invocation" support.
>> The fact that it only supports activation on a local host seems to be a bug
>> to me.
> I understand that this is a bit frustrating but I think we should at least
> explore relaxing the specification (if it hasn't been explored already). I'm
> not an export on RMI but I'm just concerned that the currently "agreed"
> solution to do the activation on another system feels more like a solution to
> get tests to pass. Stuart told me that he would look into it and see if
> relaxing the specification is feasible or not. Stuart - do you have anything to
Well, while one might say that I've changed my mind, I think it's more accurate
to say that Alan has corrected a mistake on my part.
I had previously thought that it was forbidden to make things optional. Alan
showed up on my doorstep the other day wondering why optionality wasn't pursued
more thoroughly, and then he showed me some examples where something was made
optional in a fairly precise manner. See for example the spec changes in this
It seems plausible to investigate similar kinds of changes for RMI Activation.
More information about the core-libs-dev