Wednesday Nov 19, 2008

Recently an issue came up to handle extended mixed content better with JAXB.

Just to clarify in the beginning, my opinion is that when somebody is designing a schema which is supposed to be machine processed (not something for some kind of UI rendering), it is a good decision to avoid use of mixed content, especially when designing a large schema with a lot of type extensions. Mapping that kind of schema to any binding framework is usually complex and leads to complications and slowdown of development. JAXB has never been designed to handle these cases in a convenient way - it is a Java XML mapping framework, and it's not possible to represent this kind of content in a hierarchy of Java objects.

General recommendation for JAXB, if you come up to a corner case is to use customizations. If none of the many customizations help, you shall use the DOM customization (https://jaxb.dev.java.net/guide/Avoid_strong_databinding.html#Mapping_to_DOM) which is able to handle 100% schema structures, like this:

With this customization, the underlying contents are stored in DOM tree, and thus you get unlimited capabilities to modify/access the tree structure. You loose the convenient JAXB mapping approach of course.

As I mentioned in the beginning, one corner case is handling multiple extensions with mixed content.

Usual way how JAXB handles this, is to generate 'content' property as List> where ? is the common denominator of the potential content. Then, using @XmlElementRefs and @XmlElementRef annotations, it specifies which elements are expected in the tree.

Since we are talking about mixed content, 'String' is one of the elements, so in the end you end up either with List<Object>, List<Serializable> or List<String>. Not very convenient, but still you can work with it in usual JAXB way.

However, the bigger problem comes when you do need to use a schema like this:

You've got the "content" property, which is supposed to hold the mixed content, but at the same time, you've got extensions which introduce another type of content. With Java, you can't put another "content" variable with another set of annotations to the subclasses. So, I decided to add one more global customization for those who cannot modify their schemas and need to handle this case directly through jaxb. The customization goes like this:

There's a proprietary annotation to allow overriding the content property with a different content. When JAXB runtime finds the dummy content property, it modifies it's internal representation of the original 'content' property to allow a larger set of elements, as defined in the annotations.

The code is in current JAXB nightly builds, so give it a try and we can improve/modify it before next release based on your comments. Either send them to JAXB forums, or directly to me.