EVALUATION
###@###.### wrote:
> Hi Ken,
>
> I'm Shanliang from jmx team, I'm studying the bugs and trying to find a workaround in JMX.
>
> I have a question about iiop serialization, I have the following 3 situations:
>
> 1) My class does not implement the method readObject(...)
>
> 2) My class implements the method readObject(...) as:
> private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
> // do nothing
> }
>
> 3) My class implements the method readObject(...) as:
> private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
> in.defaultReadObject();
> }
>
> I found that 1) and 2) got same results, is it as expected?
I'm not sure at this point.
>
> 2) and 3) are different, in fact 3) reproduces the bugs.
Good, that should provide a much simpler test case. Do you have writeObject
methods defined in cases 2 or 3?
>
>
> If I comment the call in.defaultReadObject() from some JMX classes, the bug disperse.
>
Thanks for the info. I'll update the corba.evolve test to include the extra cases.
Ken.
|
EVALUATION
The problem may be related to the addition of readObject methods to javax.management.MBeanInfo and .MBeanFeatureInfo with the addition of Descriptors to each. The method readObject(ObjectInputStream in) starts by doing in.defaultReadObject() and then reads a byte using in.read(). If the object being deserialized comes from JDK 5 then there was no writeObject, which means that in.read() should return -1 for EOF. And it does do that with RMI/JRMP. But with RMI/IIOP apparently it gets deeply confused. You can make the problem go away by testing in.available() > 0 in these methods, and deleting the useless readObject() methods in the various ModelMBean*Info classes. But you also have to delete ModelMBeanInfoSupport.readObject(), and that method is not useless, so this is not an acceptable fix.
|
Java