My latest commit finishes this effort. The original XML serialization method is still used for backward compatibility, but new code should use the serialzation/deserialization methods in UtilXml.
One of the problems I noticed with the existing code is that various technologies (SOAP and JMS) were hard-wired to the XmlSerializer class. The problem with that is, if a particular technology needs to change serialization in some way, it can't do so without potentially breaking the other technologies that share the XmlSerializer class. So, I created two facade classes to decouple SOAP and JMS from XmlSerializer. Each technology is now able to switch to a different serialization method if the need arises. Another problem I noticed with the existing code is the potential for database corruption. When GenericValues or GenericPKs are serialized, the delegator that created them is not included in the serialization. In addition, the deserialization method in XmlSerializer takes a Delegator argument, and that delegator is used for deserializing the GenericValue or GenericPK. So, it would be easy to serialize a GenericValue or GenericPK with one delegator, then deserialize it with a different delegator. I put warnings in the JavaDocs about that potential. -Adrian --- On Sat, 2/13/10, Adrian Crum <adrian.c...@yahoo.com> wrote: > From: Adrian Crum <adrian.c...@yahoo.com> > Subject: Re: XmlSerializer.java > To: dev@ofbiz.apache.org > Date: Saturday, February 13, 2010, 11:08 PM > Actually, this is turning out to be a > little tougher than it seemed at first glance - because of > SOAP. > > It's easy to check for XML serialization to/from the entity > engine because the root element is always <ofbiz-ser>. > It's easy to check for SOAP response serialization because > the root element is always <Response>. The problem is > with a SOAP request - the root element could be anything. > > From my perspective (and I know very little about SOAP, so > take this for what it is worth) OFBiz should have > SoapRequest and SoapResponse classes, and those objects > should be serialized/deserialized in XML - instead of the > current implementation. > > -Adrian > > --- On Sat, 2/13/10, Adrian Crum <adrian.c...@yahoo.com> > wrote: > > > From: Adrian Crum <adrian.c...@yahoo.com> > > Subject: Re: XmlSerializer.java > > To: dev@ofbiz.apache.org > > Date: Saturday, February 13, 2010, 8:01 PM > > I agree. That's exactly what I did in > > my local copy. :-) > > > > -Adrian > > > > --- On Sat, 2/13/10, David E Jones <d...@me.com> > > wrote: > > > > > From: David E Jones <d...@me.com> > > > Subject: Re: XmlSerializer.java > > > To: dev@ofbiz.apache.org > > > Date: Saturday, February 13, 2010, 7:58 PM > > > > > > We should at least keep the deserialization code > > around > > > forever for backward compatibility. You can > select > > which > > > deserializer to use based on the root element or > > something, > > > that shouldn't be tough. > > > > > > -David > > > > > > > > > On Feb 13, 2010, at 8:53 PM, Adrian Crum wrote: > > > > > > > I recently added the XStream library to the > > project - > > > which enables serializing/deserializing Java > objects > > to XML > > > or JSON. > > > > > > > > With that addition, the XmlSerializer class > is > > no > > > longer needed. The XStream library is more > > sophisticated and > > > extensible than the home-grown code. > > > > > > > > Switching XML serializers introduces a > potential > > > compatibility problem with existing installations > - > > since > > > Java objects are stored in the database in XML > format. > > I > > > believe I have come up with a strategy that > provides > > a > > > migration path, and I'm testing some ideas now. > > > > > > > > So, I just wanted to let the community know > what > > I > > > have in mind and see if there are any comments. > > > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
