We just had a great discussion with Eric on IRC.
Essentially his suggestion (along the same lines the Gunnar suggested)
was to use xslt to adjust the incoming documents to one version (the
latest) of the xsd and use that for jaxb.
An xslt for such a transformation can be seen here:
Hi Strong,
As per my understanding of JAXB, you can't use one set of JAXB binding
classes for unmarshalling XML files which use different schemas (or
different namespaces).
I can see the following options:
1) Generate different sets of binding classes for the different XSD
versions (namespaces) and use the right set of classes for unmarshalling a
given document based on the schema version it uses.
That's simple to follow but comes at the price of high redundancy between
the sets of binding classes and likely requires tedious copying logic to
e.g. populate the new binding classes based on the old ones.
2) Separate validation and unmarshalling into separate steps. First
perform
validation of the given instance document against the schema version it
uses (which could be discovered by e.g. examining the "version" or the
"xmlns" attribute of the root element).
If validation succeeds, perform a separate unmarshalling step, where the
binding classes would only exist for the newest schema version. When
unmarshalling a "new" instance document, nothing further is required, when
unmarshalling an "old" document, a transformation of that document
would be
required, to make it adhere to the current schema and expected
namespace of
the binding classes. Assuming that the schema was evolved in a compatible
manner (meaning old documents also adhere to the new schema except the
value of the "version" attribute and the namespace), this transformation
should be a simple transformation with XSLT, using the
"self-transformation" pattern.
The second approach is a bit more complex (and might be a bit more costly
due to the transformation), but it requires only one set of binding
classes
and frees the application code from dealing with different schema
versions.
I found
http://www.funkypeople.biz/knowledge/JavaXml-v2.pdf to be an
interesting read on that matter.
Hth,
--Gunnar
2013/3/25 Strong Liu <stliu(a)hibernate.org>
>
> Hi JAXB expert
>
> I'm trying to do the merge master onto metamodel again, but run into some
> JAXB problems and I'd like to ask for suggestions.
>
> as you know, we compile the orm.xsd to jaxb generated class, and there is
> a package-info.java generated for schema validation, this class looks
> like
>
> {code}
> @javax.xml.bind.annotation.XmlSchema(namespace = "
>
http://java.sun.com/xml/ns/persistence/orm", elementFormDefault =
> javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
> package org.hibernate.jaxb.spi.orm;
> {code}
>
>
> but due to the namespace of orm.xsd changed since JPA 2.1 ( from "
>
http://java.sun.com/xml/ns/persistence/orm" to "
>
http://xmlns.jcp.org/xml/ns/persistence/orm", btw, any idea why? )
>
> for now, I created a org.hibernate.jaxb.internal.LegacyJPAEventReader,
> which will modify the legacy namespace to the new one ( also changing the
> version to 2.1 )
> but with this applied, the jaxb schema validation is always fail no
> matter
> which schema is used.
>
> so, I came up with another idea, if the original orm.xml is 2.1 then go
> ahead with jaxb validation, or, we disable jaxb schema validation and
> apply
> stax schema validation before
> org.hibernate.jaxb.internal.LegacyJPAEventReader came into play
>
> ( see org.hibernate.jaxb.internal.JaxbMappingProcessor#unmarshal ) sadly,
> it doesn't work :( validation still fail, can be reproduced by
>
org.hibernate.metamodel.internal.source.annotations.xml.OrmXmlParserTests#testInvalidOrmXmlThrowsException
>
> so, any suggestions?
> -------------------------
> Best Regards,
>
> Strong Liu <stliu at hibernate.org>
>
http://about.me/stliu/bio
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev