You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@yahoo.com> on 2010/02/14 04:53:35 UTC
XmlSerializer.java
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
Re: XmlSerializer.java
Posted by Adrian Crum <ad...@yahoo.com>.
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 <ad...@yahoo.com> wrote:
> From: Adrian Crum <ad...@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 <ad...@yahoo.com>
> wrote:
>
> > From: Adrian Crum <ad...@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 <de...@me.com>
> > wrote:
> >
> > > From: David E Jones <de...@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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
Re: XmlSerializer.java
Posted by Adrian Crum <ad...@yahoo.com>.
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 <ad...@yahoo.com> wrote:
> From: Adrian Crum <ad...@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 <de...@me.com>
> wrote:
>
> > From: David E Jones <de...@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
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
Re: XmlSerializer.java
Posted by Adrian Crum <ad...@yahoo.com>.
I agree. That's exactly what I did in my local copy. :-)
-Adrian
--- On Sat, 2/13/10, David E Jones <de...@me.com> wrote:
> From: David E Jones <de...@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
> >
> >
> >
> >
>
>
Re: XmlSerializer.java
Posted by David E Jones <de...@me.com>.
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
>
>
>
>