Tuesday, 27 November 2012

XStream-ly annoying

For many of our RESTful web services, we use XStream to serialise and deserialise to and from XML.
Unfortunately, XStream does not play nice when it encounters something it does not recognise.

Say XStream is used to serialise a class of the following form:

public class BoringClass {
 private String something;
 public String getSomething(){
  return something;
 }
 public void setSomething(String something){
  this.something = something;
 }
}

To the following XML:

<boring>
 <something>value1</something>
</boring>

That's all very well, but if you want it to deserialise the following to an instance of BoringClass:


<boring>
 <something>value1</something>
 <somethingelse>value2</somethingelse>
</boring>

Rather than ignore the unrecognised element, it throws an exception.

"Why are you sending it that, then?" I hear you ask.  Well, if something new is added to the domain model in a service, a client of that service that uses XStream to deserialise the responses will need to know about the changes that have happened to that domain object (rather than just ignoring the additional elements in the XML).
This meant that an update of one service turned into an update to 10+ applications, even though most of these do not need to deal with this additional detail on the domain object.

After spending a little time looking into the problem, there are things that can be done, but they seem to get complicated rather quickly.  So much so, that manually creating and parsing XML with Dom4J appears more appealing than faffing with the internals of XStream!

Therefore, we are now concerning any reliance on XStream to be technical debt.

JSON is cooler than XML anyway.

No comments: