Ok, think I've got it really solved now (at least for one test case).
My reasoning below was correct, but there was another underlying root
cause. Serialization of the Stub class was broken for a couple of
reasons. First of all, I inadvertently added the
readObject()/writeObject() methods with public rather than private
access. Apparantly, serialization will only call them if they're
private. Secondly, The Stub() class was relying on the constructor to
set up the default delegate. For classes that implement readObject(),
writeObject(), the no argument constructor is NOT called, which was
something I'd noticed in my debugging that puzzled me at the time.
Rick
Rick McGuire wrote:
Ok, after about 7-8 days of debugging, I've finally figured out what's
going on with my RMI problem, but I don't know how to fix it. The
root of the problem is whenever a remote object (i.e., a stub) is gets
serialized and then deserialized, the object is unusable because it
doesn't have a delegate set (via _set_delegate()). During
serialization, the code in RMIStubHandler.stubWriteReplace() replaces
the serialized Stub with an instance of RMIPersistentStub.
RMIPersistentStub does a _set_delegate(stub._get_delegate()) to
initialize with the same delegate value.
During deserialization, RMIPersistentStub calls
result = javax.rmi.PortableRemoteObject.narrow(this,
type);
to activate the object. But this fails because the stub
_get_delegate() throws an exception because no delegate has been set.
After much digging, and head scratching, I finally figured out why the
delegate is null. The delegate field in the ObjectImpl superclass is
transient! So when this object is serialized and then deserialized,
the connection to the original object is lost. I've checked against
the Sun implementation, and it appears that field is marked transient
there too. So, I'm guessing RMIPersistentStub needs to pass the
delegate information via some other means that will survive the
serialization process. Does anybody have any suggestions on what the
appropriate fix would be?
Rick
