[hibernate-dev] JAXB question

[Gunnar Morling]

Yes, version attribute and namespace would have to be updated to the 2.1
values.

IMO it would still make sense to have a validation step using the original
schema (e.g. the 1.0 one) before, since validation with the 2.1 schema
wouldn't reject any (wrong) elements in e.g. a 1.0 document which where
actually added in a later schema version. Or would you tolerate this kind
of error?


2013/3/25 Steve Ebersole <steve at hibernate.org>

> I assume LegacyJPAEventReader is the attempt to work around that in the
> general approach discussed?
>
> I wonder if that is working though, as for sure another thing we need to
> do there is to alter the version attribute returned on the root.  If the
> incoming orm.xml, for example, says 1.0 as the version and we only update
> the namespace and attempt to validate with the 2.1 xsd, the validation will
> still fail.  The reason is that the XSDs define the version value
> statically.
>
>
>
> On Mon 25 Mar 2013 11:18:53 AM CDT, Steve Ebersole wrote:
>
>> 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:
>> http://stackoverflow.com/**questions/3463943/changing-**
>> namespace-for-xml-file-in-xsl-**translation<http://stackoverflow.com/questions/3463943/changing-namespace-for-xml-file-in-xsl-translation>
>>
>>
>>
>> On Mon 25 Mar 2013 10:38:51 AM CDT, Gunnar Morling wrote:
>>
>>>
>>> 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<http://www.funkypeople.biz/knowledge/JavaXml-v2.pdf>to be an
>>> interesting read on that matter.
>>>
>>> Hth,
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2013/3/25 Strong Liu <stliu at 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<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<http://java.sun.com/xml/ns/persistence/orm>"
>>>> to "
>>>> http://xmlns.jcp.org/xml/ns/**persistence/orm<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#**testInvalidOrmXmlThrowsExcepti**on
>>>>
>>>>
>>>> so, any suggestions?
>>>> -------------------------
>>>> Best Regards,
>>>>
>>>> Strong Liu <stliu at hibernate.org>
>>>> http://about.me/stliu/bio
>>>>
>>>>
>>>>
>>>> ______________________________**_________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>
>>>>
>>> ______________________________**_________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>
>>