I've been using the default Sun JAXB implementation that ships with the Oracle JDK 1.7.
Unfortunately I have certain quite complex XSD schemas to work with and I've hit what appears to be a bug in the XSD to Java engine (described in this SO post).
It appears that only a workaround is possible and what's worse I haven't yet been able to apply the particular workaround in my individual case. What's more unsettling however is that a workaround should be required for what is in my view a very elementary case (one XSD schema referencing an element defined in another).
I know of at least two other JAXB implementations:
Apache Camel
EclipseLink MOXy
Would anyone have any insights into how these compare against each other and against Sun's JAXB ?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
Apache Camel - I believe Apache Camel just leverages JAXB and is not a JAXB
(JSR-222) implementation itself.
EclipseLink MOXy - There are many great reasons to switch to MOXy (XPath based mapping, external mapping metadata, JSON-binding, etc). But MOXy uses the XML Schema to Java Compiler (XJC) tool from the JAXB reference implementation so it won't fix this use case.
Related
Is it possible to create Prolog-specific bindings of XML schema files? If so, can anybody point me in the right direction?
I have a schema which I use in Java to create a JAXB binding to serialize and de-serialize XML files. These files are created by an SWI-Prolog application which is still evolving and is developed by a geographically distant team. I want to make sure that when XML format changes, they are tied to a schema file change and not just view a schema as a nice documentation tool which often lags their actual XML content.
Any suggestions are appreciated.
Sounds like the general consensus is to use Prolog's JPL package to wrap a JAXB binding in Java. This is the closest one seems to get to an actual binding implementation.
There is an SGML package which is used by many, but this is not a binding. As far as I understand, the best one can hope for is to be able to validate one's XML against the schema, but a quick look at the SGML documentation did not give me an impression that this functionality is actually fully implemented.
So, if one needs a schema binding-style XML management framework, the recommendation is to access JAXB binding of this schema via JPL. Some folks expressed stability concerns of JPL. They reported frequent crashes of JVM when using JPL, but I have not independently verified these claims and thus cannot confirm them. If anybody has more input on this topic, I would love to get it.
Thanks
Using maven, there are a couple of plugins to support e.g. generation of JAXB classes from XSD, e.g. org.codehaus.mojo:jaxb2-maven-plugin and org.jvnet.jaxb2.maven2:maven-jaxb2-plugin.
The newest version of those have dependencies to e.g. org.glassfish.jaxb:jaxb-xjc and org.glassfish.jaxb:jaxb-runtime (in version 2.2.11).
But I wonder what would happen if I used those to generate my classes from XSD but use JDK 8 only (which contains version 2.2.8) at runtime: wouldn't there be a risk that I get runtime errors?So is it necessary or recommended to always use the jaxb-runtime corresponding to the jaxb-xjc version I used to generate my classes from XSD?
Of course I could simply override the dependencies to jaxb-xjc etc. and explicitly use version 2.2.8. But even then I wonder if I would get the same result as if I used JDK 8 xjc tool directly?
You have three phases:
(1) generation of the schema-derived code
(2) compilation of the schema-derived code
(3) runtime
The most important that JAXB API you use to compile (2) is compatible with JAXB API you use in runtime (3). If this is not the case then you might compile code which uses some annotation which is later not available in the runtime. And you'll see the error first in the runtime.
As for (1) vs. (2), this is also necessary. If you generate with JAXB 2.2.x and use JAXB 2.1.x to compile, this will not necessarily work. But this is less critical as this will be a compilation error which you will be forced to correct.
So if you problem is just JAXB version used by the maven-jaxb2-plugin vs. JAXB version embedded in JDK, I wouldn't worry about this. As long as it compiles, you're as safe as you can ever be.
The optaplanner uses XStream for reading the solver configuration from XML. For using JAXB instead, is it sufficient to have custom implementation of XMLSolverFactory and SolverConfig?
No, because the *Config classes aren't annotated with JAXB annotations in 6.0.0.
There's a open discussion if we want to migrate from XStream to JAXB, so we can offer an XSD of the solver config.
Also note, that these 2 things are completely distinct:
read a solver configuration from XML
read a solution dataset from XML (~ProblemIO)
For 2), you can very easily replace XStreamProblemIO with a JaxbProblemIO (which should be easy to write).
We are using Castor for marshalling/unmarhalling xsd:s. We are using attachments and refering to the with the "swaRef" element. According to this page Castor does not support this, http://docs.codehaus.org/display/CASTOR/Castor+JAXB:
Some of the functionality could require to be actually implemented in
backing Castor framework - for example handling the attachment
through MTOM/XOP and swaRef.
How can we overcome this limitation?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
My recommendation would be to use a standard JAXB (JSR-222) implementation that supports everything you need (models generated from XML schema, swaref, etc) rather than implementing some workaround to use Castor. An implementation is included in the JDK/JRE as of Java SE 6, and other implementations (such as MOXy) are also available.
Note
Based on the link you provided it does not appear as though Castor has run the JAXB (JSR-222) compliance tests and in the "Functional testing" section on that page it appears as though Castor has not fully tested its support for the JAXB (JSR-222) annotations.
Functional testing
I think a little bit of time should be spend on
functional testing, and this might get quite tedious. Looking, for
example, at the #XmlAttribute annotation, there's a lot of variants to
test, requiring POJOs to be annotated slightly different for each test
case. That would require us to write a lot of POJOs and wire them up
accordingly in the test classes. Let's see whether we can agree on how
to go about this (layout, package structures, ...).
when i compile a JAXB schema the generated classes are decorated with generic Javadoc comments.
is it somehow possible to suppress generating these comments?
Annotation to disable JavaDocs
Not if you're using Sun's JavaDocs tool.
They have a feature request for it, but it's been in low priority since 1997.
You can write a custom doclet to overcome this, or use a 3rd-party tool (DocFlex or such).