Jan 25, 2010

Using JPA and JAXB Annotations in the Same Object

Recently, I started working on some projects where I had to prototype various service end point technologies, including REST and AMF.  During this process, I worked out a fairly nice prototype project template that makes setting up a project fairly simple and quick.  I plan to write about the template more fully in a forthcoming post, but for now wanted to share a small gotcha that took me a bit to figure out.

I’m using JPA for persistence and JAXB to produce XML to some of the end points.  I’ve also been using annotations to minimize the amount of XML configuration that I have to do.  Things were going really well, until I wanted to customize the XML representation of one of my domain object members as well as persist it.  The member was a date and I wanted a simple month-day-year display rather than JAXB’s default locale formatting.  I started out with:

@Entity
@XmlRootElement
public class Person implements Serializable {

  @Temporal(TemporalType.DATE)
  private Date birthDate;

  public Date getBirthDate() {
    return birthDate;
  }

  public void setBirthDate(Date birthDate) {
    this.birthDate = birthDate;
  }
}

This worked but when I retrieved my XML via the REST end point my dates looked like:

<birthDate>1987-11-01T00:00:00-06:00</birthDate>

Kind of ugly.  Since formatting dates is quite common in the problem domain that these technologies would eventually be used in, I decided to add an example of it to the prototype.  I wrote a quick date adapter class:

import java.text.SimpleDateFormat;
import java.util.Date;

import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
 // the desired format
 private String pattern = "yyyy-MM-dd";

 public String marshal(Date date) throws Exception {
 return new SimpleDateFormat(pattern).format(date);
 }

 public Date unmarshal(String dateString) throws Exception {
 return new SimpleDateFormat(pattern).parse(dateString);
 }
}

And simplistically tried to set it up by adding the annotation to the member declaration.

@Entity
@XmlRootElement
public class Person implements Serializable {

  @Temporal(TemporalType.DATE)
  @XmlJavaTypeAdapter(value=DateAdapter.class)
  private Date birthDate;

  public Date getBirthDate() {
    return birthDate;
  }

  public void setBirthDate(Date birthDate) {
    this.birthDate = birthDate;
  }
}

When I went to marshall the object, I hit an IllegalAnnotationException.

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
Class has two properties of the same name "birthDate"

It took a bit to figure out what was going on, and there was surprisingly little information or examples that tried to do this sort of thing when I searched around.   Eventually, I figured out what might be obvious to some.  The trick is to separate the two types of annotations and only use the JPA annotation on the member declaration and the JAXB annotation on the accessor (get) method.  When I altered my code to this:

@Entity
@XmlRootElement
public class Person implements Serializable {

  @Temporal(TemporalType.DATE)
  private Date birthDate;

  @XmlJavaTypeAdapter(value=DateAdapter.class)
  public Date getBirthDate() {
      return birthDate;
  }

  public void setBirthDate(Date birthDate) {
    this.birthDate = birthDate;
  }

}

Everything started working as expected.  Hopefully this can be helpful to anyone that encounters a similar situation.

About the Author

Object Partners profile.

One thought on “Using JPA and JAXB Annotations in the Same Object

  1. Mark says:

    thank you this just fixed a problem i had been banging my head against for hours

  2. Anton says:

    I tried to mix JPA and JAXB too in my domain model. When I do marshalling of persistent objects I get an exception:

    org.jboss.arquillian.test.spi.ArquillianProxyException: javax.xml.bind.MarshalException : null [Proxied because : Original exception not deserilizable, ClassNotFoundException]
    at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326)
    at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251)
    at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)

    I found that due to JPA-proxying JAXB annotations must be placed at getter level and not at field level. Removing @XmlAccessorType(XmlAccessType.FIELD) solved my problem.

    Note: in this case JAXB will also require a setter, otherwise during unmarshalling it will attempt to access field directly and will throw the same exception. If you want to make a field read-only at api-level (but not for JAXB) simply define a setter as protected.

  3. Fabio says:

    Thank you for this post. This was taking my head for hours.

  4. Rafael says:

    no wasting time reading this, tank u !

  5. Volodymyr Stadnyk says:

    Thanks!
    Very helpful article!!!

    And the last paragraph costs as a gold, because saved my nerves 🙂

Leave a Reply to Fabio Cancel reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]