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
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:
>
>
> ...
>
> 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:
...
...
This would not be legal as per the 1.0 schema, since
"delimited-identifier
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 fro
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
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 ve
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://stac
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)
Not a JAXB expert, so take this all with a grain of salt...
http://docs.oracle.com/javaee/5/api/javax/xml/bind/annotation/XmlSchema.html
is completely unintelligible to me. I guess it assumes a certain level
of XML/JAXP knowledge that I simple lack.
I'd be interested to see what happens if you
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
{cod
10 matches
Mail list logo
