[
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