HalBuilder HAL-XML Serialization of Inner Beans

[John Watzke]

   Hi all, first thanks for working on a great tool for a great spec.  I plan on using HalBuilder to output HAL in my next REST API.  I've got a question about HAL-XML serialization of inner beans because I seem to be having trouble with it and I'm not sure if it is a bug or if I'm doing something wrong.

   Let's say I have a bean called PaymentBean that contains a bunch of inner beans like one for shipping information among other like beans.  Here's a short snippet:

StandardRepresentationFactory representationFactory = new StandardRepresentationFactory();

representationFactory.withFlag(StandardRepresentationFactory.PRETTY_PRINT);

Representation representation = representationFactory.newRepresentation();

PaymentBean bean = new PaymentBean();

bean.setMerchant("revent");

ShipToBean shipTo = new ShipToBean();

shipTo.setTitle("Mr");

shipTo.setCity("Austin");

shipTo.setCompany("Joe's Coffee");

shipTo.setCountry("US");

shipTo.setCounty("Travis");

shipTo.setEmail("j...@example.com");

shipTo.setFirstName("Joe");

shipTo.setLastName("Smith");

shipTo.setMiddleName("J");

shipTo.setPostalCode("77476");

bean.setShipTo(shipTo);

representation.withBean(bean);

System.out.println(representation.toString(StandardRepresentationFactory.HAL_XML));

   When I get the output, it looks like this:

<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   <billTo xsi:nil="true" />

   <merchant>revent</merchant>

   <shipTo>com.example.ShipToBean@22b7ff0e</shipTo>

</resource>

   It looks like the XML renderer isn't introspecting the inner bean.  The JSON renderer seems to work fine.  It seems like a bug but I wanted to check that I didn't need to do something else to get the XML renderer to properly serialize the inner beans.

   Here's the JSON version: 

{

  "billTo" : null,

  "merchant" : "revent",

  "shipTo" : {

    "title" : "Mr",

    "firstName" : "Joe",

    "middleName" : "J",

    "lastName" : "Smith",

    "suffix" : null,

    "street1" : null,

    "street2" : null,

    "street3" : null,

    "street4" : null,

    "city" : "Austin",

    "county" : "Travis",

    "state" : null,

    "postalCode" : "77476",

    "country" : "US",

    "company" : "Joe's Coffee",

    "phoneNumber" : null,

    "email" : "j...@example.com"

  }

}

   -- John Watzke   

[John Watzke]

And I forgot to mention the version I'm using which is 3.0.1.

[Mark Derricutt]

Hi John,

Cheers for the kind words - what you've hit on is somewhat a cross behind a bug, a design "feature", a somewhat begrudgingly changed JSON serializer, and a solution going forward all in one!

Up until the 3.0.1 core release which broke out the serializers/deserializers from the core project, I was trying to keep feature parity and round-trippyness for all changes on the JSON/XML sides of things - i.e. read in JSON, write out to XML, reading the XML, write out the JSON, and have it match.

Unfortunately as most people seem to be using the JSON variant, and it also being the only one really maintained/being evolved currently maintaining that round-trippyness was starting to hinder progress on the project - so things were ripped out to separate sub-projects which means the XML and JSON can evolve independently.

Part of the problem I found with embedding ( more collections than straight sub-objects ) was a lack of consistency in how -everyone- does it in XML, theres some standard idioms but they're not fool proof. And more often than that, I find that if you wanting to embed a collection, or a sub-object that probably wants to be an _embedded resource ( not always tho ).

This shouldn't be too hard to fix tho, I suspect its just a flag/setting on the XML parser.  I'll take a look as soon as I get some free time over the next few days. Or, feel free to submit a pull request.

Mark