JAXB - Beans to XSD or XSD to beans?_问答_开发者

I have an existing data model. I would like to express this data model in terms of XML.

It looks like I have two options if I'm to use JAXB:

Create an XSD that mirrors my data model, and use xjc to create binding objects. Marshalling and unmarshalling will involve creating a "mapping" class that would take my existing data objects and map them to the objects that xjc created. For example, in my data model I have a Doc class, and JAXB would create another Doc class with basically the same exact fields, and I would have to map from my Doc class to xjc's Doc class.
Annotate my existing data model with JAXB annotations, and use schemagen to generate an XSD from my annotated classes.

I can see advantanges and disadvantages of both approaches. It seems that most p开发者_开发技巧eople using JAXB start with the XSD file. It makes sense that the XSD should be the gold standard truth, since it expresses the data model in a truly cross-platform way.

I'm inclined to start with the XSD first, but it seems icky that I have to write and maintain a separate mapping class that shuttles data in between my world and JAXB world.

Any recommendations?

Having the XSD generated from the existing classes sounds to me like the safest way to go.

However methinks that unless you know JAXB well then the approach with annotating your own classes may turn out to be extremely frustrating (in both pain and time :)).

This has happened to me in a related context when I tried to manually extract superclass from JAXB generated classes and then marshal the instances to XML. I was getting various (cryptic) JAXB exceptions. True, my JAXB knowledge is not that deep yet.

If you insist on using JAXB then I suggest to consider using the first approach (XSD + XJC) as a way to obtain initial JAXB annotations for your classes.

You can use XSD + XJC to get an idea how to annotate your own classes. Then you can try and fit the correct annotations onto them. Start with the more complex classes (references, inheritance, list of references, list of references to abstract base class) early on.

Using another technology to generate XSD from non-annotated classes as a kick start on the XSD may help. Or you may go for an XSD that covers most of what your classes use.

If the intention of this effort is to be also able to marshal the instances into XML, then I suggest to be on watch for JAXBElement. In some cases (which I cannot pin point due to lack of knowledge) instances will not marshal unless they are wrapped in a JAXBElement.

We use HyperJAXB to generate persistence tier based on a set of XSDs. The generated classes are also used for marshaling. We have plenty of 'fun' making this to work esp. because of IDREFs and JAXBElement.

Reading between the lines, I believe the following is true:

You have your desired object model.
You have the desired XML schema, or atleast a pretty good idea of how you want it to look.

This scenario is usually referred to as "meet in the middle" mapping. It is only partially solved by JAXB. Luckily since JAXB is a specification, there are other implementations such as EclipseLink JAXB (MOXy) you can use.

MOXy offers an XPath based mapping extension that allows you to map between the Java model you have and the XML schema you want:

http://bdoughan.blogspot.com/2010/09/xpath-based-mapping-geocode-example.html
http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/GettingStarted/MOXyExtensions

You can use xjc and still have only one class with XML annotations that will server as a data object. But that is in case you are not re-generating the classes on each built.

And as code-generation is in my opinion as in, to the question of where to start from I'd suggest start from the classes. Because if you have your classes as a starting point, you will never need to re-generate these classes. And with time your classes with start to grow - including @XmlTransient, inheritance, helper methods and other (JPA) annotations.

You're pretty much at the worst possible starting point for JAXB. In your position, I'm thinking JiBX might a better bet, it can generate schema from a non-annotated class model, and then bind XML back on the object model at runtime, without using annotations.

The solution we have gone with is to have a separate project containing all of the data models defined by xml schemas from which java classes are derived using JAXB. Other projects that use the data models depend on this schemas package.

In this way, all of the "contracts" between projects are defined in a single place, using the nice portable xsd representation. There is no need for any mapping classes because we just use the JAXB generated ones directly.