MOXy's @XmlVariableNode - Using a Map's Key as the Node Name

People often ask me how they can map a java.util.Map such that the keys become the node names.  In this post I will demonstrate how this can be done using the new Variable Node mapping that we have added in EclipseLink MOXy.

You can try this out today using a nightly build of EclipseLink 2.6.0:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

JAXB and java.util.Map

Is it ironic that it can be difficult to map the java.util.Map class in JAXB (JSR-222)?  In this post I will cover some items that will make it much easier.

Removing JAXBElement From Your Domain Model

JAXBElement is a JAXB (JSR-222) mechanism that stores name and namespace information in situations where this can not be determined from the value or mapping.  For example in the class below the elements billing-address and shipping-address both correspond to the Address class.  In order to be able to round trip the data we need to keep track of which element we unmarshalled.

import javax.xml.bind.JAXBElement;
import javax.xml.bind.annotation.*;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Customer {

    @XmlElementRefs({
        @XmlElementRef(name = "billing-address"),
        @XmlElementRef(name = "shipping-address")
    })
    private JAXBElement<Address> address;

}

While useful JAXBElement can get in the way if you want to use your domain model with something like JPA (which doesn't know what to do with it).  In this post I will demonstrate how you can eliminate the need for JAXBElement through the use of an XmlAdapter.

JAXB and Package Level XmlAdapters

The XmlAdapter mechanism in JAXB (JSR-222) allows an unmappable class to be converted to a mappable one.  An XmlAdapter can be registered with the @XmlJavaTypeAdapter at the field, property, type, or package level.  This post will focus on the scope of the XmlAdapter when registered at the package level.

Mapping an Arbitrary List of Objects using JAXB's @XmlAnyElement and XmlAdapter

The @XmlAnyElement annotation enables a property to handle arbitrary XML elements, and the XmlAdapter provides a way to convert an object that can not be mapped into one that can.  In this post we will combine these two mechanisms  to map a list of arbitrary objects.

This post will cover the following concepts:

1. The @XmlAnyElement annotation
2. A type level XmlAdapter
3. Marshalling/Unmarshalling root level simple data types (i.e. String and Integer)
4. Specifying a root element via JAXBElement
5. Specifying the type to be unmarshalled on the Unmarshaller

JAXB and Inheritance - Using XmlAdapter

In previous posts I have covered how to map inheritance relationships in JAXB. This can be done by element name (via @XmlElementRef), by the xsi:type attribute, or in EclipseLink MOXy using another XML attribute (via @XmlDescriminatorNode/@XmlDescriminatorValue).  In this post the type indicator will be an XML attribute/element unique to that type, and we will leverage an XmlAdapter to implement this behaviour.

Mixing Nesting and References with JAXB's XmlAdapter

Recently I came across a question on Stack Overflow asking if JAXB could marshal the first occurrence of an object as containment and all subsequent occurrences as a reference.  Below is an expanded version of my answer (up votes appreciated) demonstrating how this can be achieved by leveraging JAXB's XmlAdapter.

XML Schema to Java - Generating XmlAdapters

In previous posts I have demonstrated how powerful JAXB's XmlAdapter can be when starting from domain objects.  In this example I will demonstrate how to leverage an XmlAdapter when generating an object model from an XML schema.  This post was inspired by an answer I gave to a question on Stack Overflow (feel free to up vote).

JSON Binding with EclipseLink MOXy - Twitter Example

In a previous post I described how the Jettison library could be used with any JAXB implementation (Metro, MOXy, JaxMe, etc) to produce/consume JSON.  Now I'll demonstrate the native object-to-JSON binding MOXy JAXB introduced in EclipseLink 2.4.  With MOXy as your JAXB provider you can produce/consume JSON using the standard JAXB APIs (available in Java SE 6) without adding any compile time dependencies.

You can try this out now using a download available from:

• http://www.eclipse.org/eclipselink/downloads/

JAXB and Joda-Time: Dates and Times

Joda-Time provides an alternative to the Date and Calendar classes currently provided in Java SE.  Since they are provided in a separate library JAXB does not provide a default mapping for these classes.  We can supply the necessary mapping via XmlAdapters.  In this post we will cover the following Joda-Time types:  DateTime, DateMidnight, LocalDate, LocalTime, LocalDateTime.

Represent String Values as Element Names with JAXB ("foo" as <foo/>)

In this example we will map a String value to an element name.  Instead of <foo>bar</foo> we want <bar/>.  We will accomplish this by using @XmlAdapter and @XmlElementRef.

JAXB and Immutable Objects

I was recently sent a blog post:  JAXB and immutable objects, by Aniket Shaligram.  In this post the author addresses the issue by adding a default constructor and using field access, to avoid adding set methods.  This approach is perfectly valid, but leaves the class being more mutable than some people like (including the person who sent me the link).  In this post I'll discuss an alternative approach using XmlAdapter.

XmlAdapter - JAXB's Secret Weapon

The XmlAdapter mechanism in JAXB ensures that there is no such thing as an unmappable class (with a little programmatic help). However there appears to be some confusion on how to use XmlAdapter, below is the general concept:

1. Identify the unmappable class
2. Create an equivalent class that is mappable
3. Create an XmlAdapter to convert between unmappable and mappable objects
4. Specify the XmlAdapter

Part of the problem may be due to the Javadocs on the XmlAdapter class. Below I'll flush out the example used there.