United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4460983 : (spec) ActivatableServerRef could not be instantiated from RemoteObject

Details
Type:
Bug
Submit Date:
2001-05-21
Status:
Resolved
Updated Date:
2004-09-21
Project Name:
JDK
Resolved Date:
2003-08-18
Component:
core-libs
OS:
solaris_2.6,generic
Sub-Component:
java.rmi
CPU:
sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0,5.0
Fixed Versions:
5.0 (tiger)

Related Reports
Relates:
JDK-4943189 - (spec) Activatable class should be marked as not serializable

Sub Tasks

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
2004-09-22 
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
2003-08-15


Hardware and Software, Engineered to Work Together