During my investigation into security, I realised wanted to set
-Djava.rmi.server.useCodebaseOnly=true.
To achive this I set about eliminating all generation of stubs in river,
related to download jar's, except for one specifically within Phoenix
itself, that was not downloaded, but was used by Phoenix locally.
All instances of creating MarshalledObject, or creating an object using
MarshalledObject.get() were replaced with MarshalledInstance.
In the qa-harness (not part of the tests), I also replaced JRMP with JERI.
After making these changes, I could set
-Djava.rmi.server.useCodebaseOnly=true.
My reason for mentioning this, was I recently realised that for
River-336 Class loading is not used by MarshalledObject, instead
MarshalledObject uses RMI infrastructure.
Although it should probably be left until after River 3.0, I realise for
River-336 to completely Replace RMIClassLoader, we need to deprecate all
methods containing MarshalledObject (Apart from Activation constructors)
and provides alternative methods with MarshalledInstance in our api.
With this thought in mind, I considered the impact of Java 8 default
methods in interfaces. It turns out they provide a completely
acceptable method for interface evolution in River. For example, an
earlier version Service interface exists in the client, a service proxy
implementing a later interface default method is downloaded, in the
client it will no longer override the default method, as it doesn't
exist in the client jvm, this is still a binary compatible change, the
proxy and client will be compatible.
Working in the opposite direction, where a proxy from an earlier version
is downloaded into a client with a later version of the interface
including a default method, the combination will still be binary compatible.
Before reacting and rejecting this information, it's important for
people think of the consequences of not addressing this issue at some point.
Regards,
Peter.
