Writing null objects as empty elements

[John Wright-22]

Hi,

I notice that there is a longstanding enhancement request to output null objects as empty tags instead of omitting them.   In our case here on my team at Adobe, we use the XStream library to output Java objects in a REST styled API.  We don’t care as much about having perfect serialization and un-serialization, we just need a good library to output Java as XML.  Writing custom converters for each object is a huge pain in the neck, especially when other languages like Ruby, have great xml and json output options.  So I played around today with tweaking Xstream to output empty tags for null values.  On line 111 of AbstractReflectionConverter, inserting these lines seemed to do the trick:

                if (newObj == null && System.getProperty(“xstream.omit.nulls”) == null) {                    newObj = "";                    fieldType = String.class;                }
This is a hack but it does work for XML and for the JSONHierarchicalDriver (an empty String is outputed in the case of JSON).  Notice that you can turn this off via a System property but it is on by default since that is the way we want it.  Others of you who need empty tags for null objects might consider this a start.  I would submit this back to Xstream but the enhancement request has been around for 3 years so I doubt there is interest in doing this.   If anybody knows of another way todo this or another Java lib that we should be using, please let me know.  

Thanks,

John Wright

[Jörg Schaible-2]

Hi John,

John Wright wrote:

> Hi,
>
> I notice that there is a longstanding enhancement request to output null
> objects as empty tags instead of omitting them.   In our case here on my
> team at Adobe, we use the XStream library to output Java objects in a REST
> styled API.  We don't care as much about having perfect serialization and
> un-serialization, we just need a good library to output Java as XML.

This is, where we have to take a bit more care ;-)

> Writing custom converters for each object is a huge pain in the neck,
> especially when other languages like Ruby, have great xml and json output
> options.  So I played around today with tweaking Xstream to output empty
> tags for null values.  On line 111 of AbstractReflectionConverter,
> inserting these lines seemed to do the trick:
>
>                 if (newObj == null &&
>                 System.getProperty("xstream.omit.nulls") == null) {      
>                             newObj = "";                    fieldType =
>                 String.class;                }
> This is a hack but it does work for XML and for the JSONHierarchicalDriver
> (an empty String is outputed in the case of JSON).

And I am quite sure that we get quite immediately after a release a bug
report that *null* in Java is represented by *null* in JSON.

> Notice that you can
> turn this off via a System property but it is on by default since that is
> the way we want it.  Others of you who need empty tags for null objects
> might consider this a start.  I would submit this back to Xstream but the
> enhancement request has been around for 3 years so I doubt there is
> interest in doing this.

It has not been closed, other things had simply more priority or patches.
However, we are always hesitant adding stuff that will work one way only.

The *null* representation is unfortunately quite complex, since it is not
only in the domain of the converters, but depend also on the target format.
With XML you might want to add simply a 'nil' attribute, while JSON
requires  'null'. Therefore the current interface for the readers and
writers is not really prepared for this functionality. Additionally at
deserialization time the converter might be suddenly confronted with a null
value - and most of them will simply assume a valid object and fail with an
NPE then.

> If anybody knows of another way todo this or
> another Java lib that we should be using, please let me know.

All we ask of is, that you do not distribute a modified version of XStream.
However, you can easily copy the code for the
(Abstract-)ReflectionConverter, modify it for your needs and register it
afterwards with a low (or very low) priority. That way the original XStream
is kept, but the default converter is your modified code.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Wright-22]

Jörg: “All we ask of is, that you do not distribute a modified version of XStream.

However, you can easily copy the code for the
(Abstract-)ReflectionConverter, modify it for your needs and register it
afterwards with a low (or very low) priority. That way the original XStream

is kept, but the default converter is your modified code.”

Oh ok good idea, will do!


On 10/29/09 4:33 AM, "Jörg Schaible" <joerg.schaible@...> wrote:

Hi John,

John Wright wrote:

> Hi,
>
> I notice that there is a longstanding enhancement request to output null
> objects as empty tags instead of omitting them.   In our case here on my
> team at Adobe, we use the XStream library to output Java objects in a REST
> styled API.  We don't care as much about having perfect serialization and
> un-serialization, we just need a good library to output Java as XML.

This is, where we have to take a bit more care ;-)

> Writing custom converters for each object is a huge pain in the neck,
> especially when other languages like Ruby, have great xml and json output
> options.  So I played around today with tweaking Xstream to output empty
> tags for null values.  On line 111 of AbstractReflectionConverter,
> inserting these lines seemed to do the trick:
>
>                 if (newObj == null &&
>                 System.getProperty("xstream.omit.nulls") == null) {      
>                             newObj = "";                    fieldType =
>                 String.class;                }
> This is a hack but it does work for XML and for the JSONHierarchicalDriver
> (an empty String is outputed in the case of JSON).

And I am quite sure that we get quite immediately after a release a bug
report that *null* in Java is represented by *null* in JSON.

> Notice that you can
> turn this off via a System property but it is on by default since that is
> the way we want it.  Others of you who need empty tags for null objects
> might consider this a start.  I would submit this back to Xstream but the
> enhancement request has been around for 3 years so I doubt there is
> interest in doing this.

It has not been closed, other things had simply more priority or patches.
However, we are always hesitant adding stuff that will work one way only.

The *null* representation is unfortunately quite complex, since it is not
only in the domain of the converters, but depend also on the target format.
With XML you might want to add simply a 'nil' attribute, while JSON
requires  'null'. Therefore the current interface for the readers and
writers is not really prepared for this functionality. Additionally at
deserialization time the converter might be suddenly confronted with a null
value - and most of them will simply assume a valid object and fail with an
NPE then.

> If anybody knows of another way todo this or
> another Java lib that we should be using, please let me know.

All we ask of is, that you do not distribute a modified version of XStream.
However, you can easily copy the code for the
(Abstract-)ReflectionConverter, modify it for your needs and register it
afterwards with a low (or very low) priority. That way the original XStream
is kept, but the default converter is your modified code.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dudleygb]

why not have an extentions section for all these custom changes, that way we can download the original XStream and then mix and match with Converters etc?

On Thu, Oct 29, 2009 at 6:31 PM, John Wright <johnw@...> wrote:

Jörg: “All we ask of is, that you do not distribute a modified version of XStream.

However, you can easily copy the code for the
(Abstract-)ReflectionConverter, modify it for your needs and register it
afterwards with a low (or very low) priority. That way the original XStream

is kept, but the default converter is your modified code.”

Oh ok good idea, will do!

On 10/29/09 4:33 AM, "Jörg Schaible" <joerg.schaible@...> wrote:

Hi John,

John Wright wrote:

> Hi,
>
> I notice that there is a longstanding enhancement request to output null
> objects as empty tags instead of omitting them.   In our case here on my
> team at Adobe, we use the XStream library to output Java objects in a REST
> styled API.  We don't care as much about having perfect serialization and
> un-serialization, we just need a good library to output Java as XML.

This is, where we have to take a bit more care ;-)

> Writing custom converters for each object is a huge pain in the neck,
> especially when other languages like Ruby, have great xml and json output
> options.  So I played around today with tweaking Xstream to output empty
> tags for null values.  On line 111 of AbstractReflectionConverter,
> inserting these lines seemed to do the trick:
>
>                 if (newObj == null &&
>                 System.getProperty("xstream.omit.nulls") == null) {      
>                             newObj = "";                    fieldType =
>                 String.class;                }
> This is a hack but it does work for XML and for the JSONHierarchicalDriver
> (an empty String is outputed in the case of JSON).

And I am quite sure that we get quite immediately after a release a bug
report that *null* in Java is represented by *null* in JSON.

> Notice that you can
> turn this off via a System property but it is on by default since that is
> the way we want it.  Others of you who need empty tags for null objects
> might consider this a start.  I would submit this back to Xstream but the
> enhancement request has been around for 3 years so I doubt there is
> interest in doing this.

It has not been closed, other things had simply more priority or patches.
However, we are always hesitant adding stuff that will work one way only.

The *null* representation is unfortunately quite complex, since it is not
only in the domain of the converters, but depend also on the target format.
With XML you might want to add simply a 'nil' attribute, while JSON
requires  'null'. Therefore the current interface for the readers and
writers is not really prepared for this functionality. Additionally at
deserialization time the converter might be suddenly confronted with a null
value - and most of them will simply assume a valid object and fail with an
NPE then.

> If anybody knows of another way todo this or
> another Java lib that we should be using, please let me know.

All we ask of is, that you do not distribute a modified version of XStream.
However, you can easily copy the code for the
(Abstract-)ReflectionConverter, modify it for your needs and register it
afterwards with a low (or very low) priority. That way the original XStream
is kept, but the default converter is your modified code.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi,

Dudley Butt wrote:

> why not have an extentions section for all these custom changes, that way
> we can download the original XStream and then mix and match with
> Converters etc?

somebody has to maintain it nevertheless?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Joe Walnes-3]

Something that may help, is if we were move the hosting of XStream to something like GitHub or BitBucket, it lowers the barrier of entry for someone to fork the project, make their own changes, and publish them to the world, without getting the blessing of the main team. It also makes it easier for all these forks to be tracked and the more popular changes to be merged upstream in the future. 

Just a thought. This model is working well for me on other projects.

cheers

-Joe

On Tue, Nov 3, 2009 at 5:50 PM, Jörg Schaible <joerg.schaible@...> wrote:

Hi,

Dudley Butt wrote:

> why not have an extentions section for all these custom changes, that way
> we can download the original XStream and then mix and match with
> Converters etc?

somebody has to maintain it nevertheless?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Joe,

Joe Walnes wrote at Mittwoch, 4. November 2009 01:40:

> Something that may help, is if we were move the hosting of XStream to
> something like GitHub or BitBucket, it lowers the barrier of entry for
> someone to fork the project, make their own changes, and publish them to
> the world, without getting the blessing of the main team. It also makes it
> easier for all these forks to be tracked and the more popular changes to
> be merged upstream in the future.
>
> Just a thought. This model is working well for me on other projects.

I am simply not at all familiar with git yet and have currently not a lot of
time ... ;-)

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email