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", 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" to "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#testInvalidOrmXmlThrowsException so, any suggestions? ------------------------- Best Regards, Strong Liu <stliu at hibernate.org> http://about.me/stliu/bio _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 to be an interesting read on that matter. Hth, --Gunnar 2013/3/25 Strong Liu <stliu(a)hibernate.org&gt; > > 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";, 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" to " > 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#testInvalidOrmXmlThrowsException > > so, any suggestions? > ------------------------- > Best Regards, > > Strong Liu <stliu at hibernate.org> > http://about.me/stliu/bio > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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/q... > > > > 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.funky... be an >> interesting read on that matter. >> >> Hth, >> >> --Gunnar >> >> >> >> 2013/3/25 Strong Liu <stliu(a)hibernate.org&gt; >> >> >>> 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/n...;, >>> 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/n... >>> to " >>> http://xmlns.jcp.org/xml/ns/**persistence/orm<http://xmlns.jcp.org/xml...;, >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists... >>> >>> >> ______________________________**_________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists... >> >

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.

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>> > > > 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... > > <http://stackoverflow.com/**questions/3463943/changing-** > namespace-for-xml-file-in-xsl-**translation<http://stackoverflow.com/q... > > > > > > 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.fun... > > <http://www.funkypeople.biz/**knowledge/JavaXml-v2.pdf<http://www.funky... > to be an > interesting read on that matter. > > Hth, > > --Gunnar > > > > 2013/3/25 Strong Liu <stliu(a)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... > > <http://java.sun.com/xml/ns/**persistence/orm<http://java.sun.com/xml/n... > >", > 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... > <http://java.sun.com/xml/ns/**persistence/orm<http://java.sun.com/xml/n... > to " > http://xmlns.jcp.org/xml/ns/__**persistence/orm<http://xmlns.jcp.org/x... > > <http://xmlns.jcp.org/xml/ns/**persistence/orm<http://xmlns.jcp.org/xml...;, > 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://about.me/stliu/bio > > > > ______________________________**___________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev@lists.jboss.org> > > > https://lists.jboss.org/__** > mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listi... > <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists... > **> > > > ______________________________**___________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev@lists.jboss.org> > > > https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lis... > <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists... > **> > > >

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>__> > > >