[jboss-jira] [JBoss JIRA] Commented: (JBSER-98) Write slot with fields only if both readObject and writeObject are missing

[Galder Zamarreno (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSER-98?page=comments#action_12388917 ] 
            
Galder Zamarreno commented on JBSER-98:
---------------------------------------

I have done a bit of research on this:

- If you mark a class/interface as Serializable, there're could be situations 
where readObject() might be implemented but not writeObject(), for 
example any post-construction activities that you want your object to deal 
with such as initialization of transient fields, validation, registering for events,
 etc. then you should implement readObject(). Such readObject() implementation 
should be calling defaultReadObject() first.

- Similar thing could happen with a writeObject() implementation that calls 
defaultWriteObject() and then registers some kind of event.

As long as the actual serialized stream is not changed, readObject()/writeObject() 
could appear without one another. I don't think JBoss Serialization can however be 
able to determine whether the actual implementation of those methods are 
changing the serialization or not.

I used the following two links as reference:
http://www.onjava.com/pub/a/onjava/excerpt/JavaRMI_10/index.html?page=3
http://www.jguru.com/faq/view.jsp?EID=120641

Bottom line: we need to handle such situations.

> Write slot with fields only if both readObject and writeObject are missing
> --------------------------------------------------------------------------
>
>                 Key: JBSER-98
>                 URL: http://jira.jboss.com/jira/browse/JBSER-98
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>    Affects Versions: 1.0.3 GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>
> Over the last few weeks, I've been dealing with a funky support case which showed the following 
> stacktrace:
> ...
> Caused by: org.jboss.serial.exception.SerializationException: Excepted to be String
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1120)
> at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:71)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
> at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60)
> at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
> ... 28 more
> Caused by: java.lang.ClassCastException: org.jboss.serial.finalcontainers.IntegerContainer
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1116)
> ... 42 more 
> The cause of the issue was that the customer had a class where it had re-implemented 
> readObject(java.io.ObjectInputStream stream) but had not re-implemented 
> writeObject(java.io.ObjectOutputStream stream). This is obviously a programming error on their side,
> but it took a while to detect such stupid mistake.
> The problem within JBoss Serialization was that because this class didn't have a writeObject() 
> reimplementation, it was a writing the class as a slot with fields, but when it came to reading it, it 
> was reading the class as a slot with method because readObject had been reimplemented. The 
> next time a slot with fields was read, the fields were mixed up.
> To avoid these type of situations, I'd suggest that:
> - JBS only writes as fields if *both* writeObject and readObject are missing. Right now, can't see a 
> situation where you'd implement one and not the other, thoughts?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira