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 <st...@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> >> >> >> >> 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>to >>> be an >>> interesting read on that matter. >>> >>> Hth, >>> >>> --Gunnar >>> >>> >>> >>> 2013/3/25 Strong Liu <st...@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>", >>>> 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>" >>>> to " >>>> 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://about.me/stliu/bio >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev> >>>> >>>> >>> ______________________________**_________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev> >>> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
