EVALUATION
Deserializing an ActivatableServerRef could not actually do anything useful anyway, because it implies exporting an already-registered activatable object in an arbitrary VM (not necessarily the VM for the object's activation group ID) without having been activated through rmid. There is no other scenario today where such an event can occur, and it's hard to imagine how it could make sense.
Therefore, we should probably just make the failure more straightforward, and document that ActivatableServerRefs cannot be usefully deserialized.
In addition, it's probably also worthwhile to document and ensure in the implementation that ActivatableServerRefs cannot be serialized either-- they currently suffer from 4353388-like behavior (InternalError thrown when marshalled through a MarshalOutputStream-- fixed for UnicastRemoteObject but not Activatable), but they probably just should not be serialized in any case, because (from above) they can never be usefully deserialized.
peter.c.jones@east 2001-05-23
Specification is updated so that "ActivatableServerRef" is no longer a supported "external ref type name", and implementation is fixed to throw ClassNotFoundException for unrecognized external ref type names, as prescribed in specification.
###@###.### 2003-08-15
|