JDK-4460983 : (spec) ActivatableServerRef could not be instantiated from RemoteObject
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.0,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 2001-05-21
  • Updated: 2017-05-16
  • Resolved: 2003-08-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Relates :  
JDK-4943189 - (spec) Activatable class should be marked as not serializable
Description

Name: ooR10001			Date: 05/21/2001


java.rmi.server.RemoteObject class use refClass.newInstance() call before 
deserialization of remote reference from the stream in readObject() method.
But sun.rmi.server.ActivatableServerRef class has no no-arg constructor. It 
causes that instance of this class could not be instantiated in 
RemoteObject.readObject() method and InstantiationException is throw.
Suggested fix may be add the no-arg constructor to 
sun.rmi.server.ActivatableServerRef class or add analysis for the name of the 
remote reference class and in case of 'ActivatableServerRef' appropriate 
constructor should be invoked.

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
22-09-2004
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
15-08-2003