Dain Sundstrom wrote:
Don't forget to add copious comments to the code so someone else
doesn't have to repeat this painful process :)
Trust me, that's already done!
-dain
On Dec 7, 2006, at 1:14 PM, Rick McGuire wrote:
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
