NPE in HomeHandleImplIIOP

[bdecoste]

stubClass in HomeHandleImplIIOP is null after marshalling, so narrow is
throwing an NPE. Looks like changes were made a few weeks ago that cause this problem. I have corrected this by making stubClass not transient. If this is a problem, please let me know.

[dimitris]

If you mean the work done in:

http://jira.jboss.com/jira/browse/JBAS-4655?page=comments

then Adrian needs to verify your change.

[adrian.brock]

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?

ReadObject

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;

ReadExternal

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)
throws IOException;

[adrian.brock]

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?

[adrian.brock]

I've confirmed readObject() doesn't get invoked unless it is private
so I've raised a bug report.
http://jira.jboss.com/jira/browse/JBAS-4801

[adrian.brock]

I've fixed the serialization, but I've not closed the issue until Bill confirms
it resolves the problem he was seeing.

[aloubyansky]

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

[adrian.brock]

The only way I can see that the StubClass would become a jacorb reference
is if something is invoking the constructor
HandleImplIIOP(org.omg.CORBA.Object obj)
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.

[aloubyansky]

Ok, thanks for the tip. I'll look into that. It's the org.jboss.proxy.ejb.EjbObjectCorbaServant.

[bdecoste]

I've confirmed the latest fix resolves the EJB3 IIOP test issue and resovled the JIRA. Thanks.