Also, please add test cases as you fix the issues... Currently, the RMI area lacks tests...
- Balaji -----Original Message----- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 5:52 PM To: yoko-dev@incubator.apache.org Subject: Re: I think I found my RMI problem....now how do I fix it? Don't forget to add copious comments to the code so someone else doesn't have to repeat this painful process :) -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 >>
