[hibernate-dev] JAXB question

Gunnar Morling gunnar at hibernate.org
Mon Mar 25 15:59:13 EDT 2013


> 2) I am not sure what exact scenario you are are thinking about, but I do not see any problem with validating a 1.0 or 2.0 compliant doc with the 2.1 xsd.

I meant cases like this:

<entity-mappings version="1.0">
    ...
    <persistence-unit-defaults>
        <delimited-identifiers/>
    </persistence-unit-defaults>
    ...
</entity-mappings>

This would not be legal as per the 1.0 schema, since
"delimited-identifiers" was only added in 2.0.

Validating with the latest schema wouldn't detect this kind of error, but
as said, it might well be that this can be neglected. If not, a separate
validation using the original schema version would detect the error.


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

> Well I just noticed that the class is at least attempting to also alter
> the version in the StAX events.  We'll just have to wait to hear from
> Strong whether this setup currently out on github works or not.  It is
> essentially the approach discussed on IRC.
>
> As for performing the validation up front:
> 1) I have had no success getting this to work on master, where I am trying
> to do something similar (version specific validation).  The validation
> always passes
> 2) I am not sure what exact scenario you are are thinking about, but I do
> not see any problem with validating a 1.0 or 2.0 compliant doc with the 2.1
> xsd.
>
>
>
> On Mon 25 Mar 2013 02:34:11 PM CDT, Gunnar Morling wrote:
>
>> 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
>> <mailto: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>
>>
>>         <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>
>>
>>             <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
>>             <mailto: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>
>>
>>                 <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>
>>                 <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>
>>
>>                 <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://hibernate.org
>> >>
>>                 http://about.me/stliu/bio
>>
>>
>>
>>                 ______________________________**___________________
>>                 hibernate-dev mailing list
>>                 hibernate-dev at lists.jboss.org
>>                 <mailto:hibernate-dev at lists.**jboss.org<hibernate-dev at lists.jboss.org>
>> >
>>                 https://lists.jboss.org/__**
>> mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>>                 <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
>>             <mailto:hibernate-dev at lists.**jboss.org<hibernate-dev at lists.jboss.org>
>> >
>>             https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>>             <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> **>
>>
>>
>>


More information about the hibernate-dev mailing list