[hibernate-dev] JAXB question
Strong Liu
stliu at hibernate.org
Tue Mar 26 03:33:38 EDT 2013
Okay, thanks guys
I think the best option ( for now ) is :
1. using org.hibernate.jaxb.internal.LegacyJPAEventReader to tweak the jpa 1.0 / 2.0 to match 2.1 namespace and version attribute
2. using jpa 2.1 schema to do the validation ( though it might happen what Gunnar said )
code pushed and all tests pass
On Mar 26, 2013, at 4:02 AM, Steve Ebersole <steve at hibernate.org> wrote:
> True. But not sure we care.
>
> On Mon 25 Mar 2013 02:59:13 PM CDT, Gunnar Morling wrote:
>> |>|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
>> <mailto: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>
>> <mailto: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>
>> <mailto: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://hibernate.org>>
>> http://about.me/stliu/bio
>>
>>
>>
>>
>> ___________________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> <mailto:hibernate-dev at lists.jboss.org>
>> <mailto:hibernate-dev at lists.__jboss.org
>> <mailto: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>
>> <mailto:hibernate-dev at lists.__jboss.org
>> <mailto: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>__>
>>
>>
>>
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
More information about the hibernate-dev
mailing list