You can't make the stubClass non-transient. That breaks serialization
compatibility with older versions.
In fact, it shouldn't work, there is a readObject method.
The stubClass is re-initialized in that method.
My guess is that the read/writeObject() methods are not getting invoked
because according to the spec they should be private instead of public.
They are private for the HandleImplIIOP.
This is probably a confusion between readObject and readExternal
in the original development?
For serializable objects, the readObject method allows a class to control the deserialization of its own fields. Here is its signature:
private void readObject(ObjectInputStream stream)
throws IOException, ClassNotFoundException;
Objects implementing java.io.Externalizable must implement the readExternal method to restore the entire state of the object. It must coordinate with its superclasses to restore their state. All of the methods of ObjectInput are available to restore the object's primitive typed fields and object fields.
public void readExternal(ObjectInput stream)
Actually, fixing this will break serialization compatibility, but I don't see any other
mechanism. We are required by spec to run the handle serialization through
the handle delegate.
It's obviously never worked properly for HomeHandles!
I'd guess to fix this, we need to add a system property such that the
serlialization works in either the old or new way?
I've fixed the serialization, but I've not closed the issue until Bill confirms
it resolves the problem he was seeing.
There is also a problem with the stubClass being set to org.jacorb.orb.Reference.
This can be reproduced in a CTS5 test. Though in the test it occurs in the HandleImplIIOP, the logic seems to be the same.
Adrian started fixing the real problem in http://jira.jboss.com/jira/browse/JBAS-4655
The CTS issue is http://jira.jboss.com/jira/browse/JBCTS-660
The only way I can see that the StubClass would become a jacorb reference
is if something is invoking the constructor
with the reference without doing some narrow() code like the handle does.
Add some debug code to the constructor to see what is passing a
corba Object that does not implement EJBObject.
Ok, thanks for the tip. I'll look into that. It's the org.jboss.proxy.ejb.EjbObjectCorbaServant.
I've confirmed the latest fix resolves the EJB3 IIOP test issue and resovled the JIRA. Thanks.