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(a)hibernate.org
<mailto:steve@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(a)hibernate.org
<mailto:steve@hibernate.org>
<mailto:steve@hibernate.org <mailto:steve@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...
<
http://stackoverflow.com/__questions/3463943/changing-__namespace-for-xml...
<
http://stackoverflow.com/__questions/3463943/changing-__namespace-for-xml...
<
http://stackoverflow.com/questions/3463943/changing-namespace-for-xml-fil...
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(a)hibernate.org
<mailto:stliu@hibernate.org>
<mailto:stliu@hibernate.org
<mailto:stliu@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(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
<mailto:hibernate-dev@lists.__jboss.org
<mailto:hibernate-dev@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(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
<mailto:hibernate-dev@lists.__jboss.org
<mailto:hibernate-dev@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>__>