[hibernate-dev] JAXB question
Steve Ebersole
steve at hibernate.org
Mon Mar 25 16:02:35 EDT 2013
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>__>
>
>
>
More information about the hibernate-dev
mailing list