XStream and default field values.

D

Daniel Pitts

Hello everyone.

Is there anyway to tell XStream to treat missing elements as empty
elements? Or, even better, let corresponding fields keep their value
from object initialization?

My explanation on why this would be useful follows.

I'm using XStream to deserialize a Java object. The XML format is
actually a published interface (at least internally) which can evolve
slowly over time.

The XStream process is replacing a Spring Binding process, and we have a
lot of framework/library code that makes certain assumptions about the
bean contents/structure. One of the assumptions is that certain
properties are not null, even if they are optional. XStream seems to be
setting the fields (which are currently final) to null, if there isn't a
corresponding value in the XML. This means that all processed XML will
need to have the optional elements present, or it will cause problems.

for example:
// Foo.java
import java.io.Serializable;
public class Foo implements Serializable {
private final Bar bar = new Bar;
private String myString;

public void doSomething() {
bar.doSomething();
}
}

// Bar.java
import java.io.Serializable;
public class Bar implements Serializable {
public void doSomething() {
System.out.println("Working!");
}
}

// Main.java
public class Main {
private static String xml =
"<foo>" +
"<myString>This is the value of myString!</myString>" +
"</foo>";

public static void main(String...args) {
XStream xStream = new XStream();
xStream.aliasType("foo", Foo.class);
Foo foo = (Foo)xStream.fromXML(xml);
foo.doSomething(); // NPE for bar.doSomething();
}
}
 
D

Daniel Pitts

Hello everyone.

Is there anyway to tell XStream to treat missing elements as empty
elements? Or, even better, let corresponding fields keep their value
from object initialization?
It looks like I may want to register a JavaBeanConverter, I'll follow up
tomorrow with what I find.
 
D

Daniel Pitts

It looks like I may want to register a JavaBeanConverter, I'll follow up
tomorrow with what I find.
It looks like XStream is not the correct approach for me at this time.
The JavaBeanConverter assumes every property that is in the XML should
be writable, where as my model assumes final embedded beans with their
own properties. My approach works perfectly for Spring binding, but I'd
have to write a very sophisticated Converter for it to work in XStream.

Someday I may do so, as an exercise, but today my solution is to drop
XStream and convert the XML to a Map with the same conventions that
Spring expects. Actually, I think XStream could be redesigned to be
more flexible and extensible. Maybe when I have some spare time. Yeah,
right, spare time.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top