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 <st...@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 <st...@hibernate.org >> <mailto:st...@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 <st...@hibernate.org >> <mailto:st...@hibernate.org> >> <mailto:st...@hibernate.org <mailto: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> >> >> >> >> <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 <st...@hibernate.org >> <mailto:st...@hibernate.org> >> <mailto:st...@hibernate.org >> <mailto: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> >> >> <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@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@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>__> >> >> >> ------------------------- 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
