[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