Just wanted to let everyone know that implementing JPA 2.1 support is moving along. I had too much work here that I was worried about losing so I went ahead and pushed it to my fork. Draft 6 from the expert group is almost completely implemented at this point. The only outstanding item left from Draft 6 is support for "AttributeConverters" which I'll start on next. If anyone wanted to start playing around with it or looking at it, like I said, its pushed to my fork: https://github.com/sebersole/hibernate-core/tree/jpa21 I went a slightly different approach with our shiny new native stored procedure support compared to the JPA approach. The hope was to make it easier to deal with the potential multiple interleaved ResultSet/updateCount returns. Let me know if anyone has design improvements there. Subquery support on CriteriaUpdate and CriteriaDelete objects is still undefined waiting for an updated spec addressing a problem there. Other than that (and the AttributeConverter stuff) I fully expect this to fully address Draft 6.

It also contains some major refactorings: 1) removal of Ejb3Configuration in preference of the new 2-phase bootstrap approach of Bootstrap/EntityManagerFactoryBuilder.

2) I renamed o.h.ejb to o.h.jpa.

Let me know if you see any problems…

Could not find group:org.hibernate.javax.persistence, module:hibernate-jpa-2.1-api, version:1.0.0.Draft-6b.

Hmmm.. let me check... On Mon 16 Jul 2012 08:45:48 AM CDT, Hardy Ferentschik wrote: > Hi, > > >> It also contains some major refactorings: >> 1) removal of Ejb3Configuration in preference of the new 2-phase >> bootstrap approach of Bootstrap/EntityManagerFactoryBuilder. > > sounds good > >> 2) I renamed o.h.ejb to o.h.jpa. > > +1 jpa is much more concise > >> Let me know if you see any problems… > > it seems you latest code depends on a Draft-6b which is not deployed > to the repository. I can only see Daft-6. > > Could not resolve all dependencies for configuration > ':hibernate-core:compile'. >> Could not find group:org.hibernate.javax.persistence, >> module:hibernate-jpa-2.1-api, version:1.0.0.Draft-6b. > Required by: > org.hibernate:hibernate-core:4.1.5-SNAPSHOT > > --Hardy > > > -- steve(a)hibernate.org http://hibernate.org

Strong, I forgot to mention that Jason completely agrees that changes to Jandex are needed. I agreed to prototype some of the things he and I discussed specifically in this code base and hand them back to him for integration back into the next rev of Jandex.

One such point of discussion was a common interface for "Index". Unfortunately the name Index is already taken as in the main Jandex class. So we came up with some other names. For this work I went ahead with the name 'IndexResult' for that common contract (interface). Anyway, no matter the name, eventually both Index and that new CompositeIndex would both implement this new common contract.

The other thing we discussed was integrating XML overrides into the indexing process since quite a few places where Jandex gets used would need this. And since you worked on that in the metamodel codebase, was hoping to get your feedback as to whether you thought it would be possible to integrate XML overrides into this process up front.

On Jul 17, 2012, at 5:58 PM, Hardy Ferentschik <hardy(a)hibernate.org <mailto:hardy@hibernate.org>> wrote: > > On Jul 16, 2012, at 9:06 PM, Steve Ebersole wrote: > >> Strong, I forgot to mention that Jason completely agrees that >> changes to >> Jandex are needed. I agreed to prototype some of the things he and I >> discussed specifically in this code base and hand them back to him for >> integration back into the next rev of Jandex. > > Nice. Maybe I can lend a hand there as well. As you know I am > strongly attached > to this issue :-) > >> One such point of discussion was a common interface for "Index". >> Unfortunately the name Index is already taken as in the main Jandex >> class. So we came up with some other names. For this work I went >> ahead >> with the name 'IndexResult' for that common contract (interface). >> Anyway, no matter the name, eventually both Index and that new >> CompositeIndex would both implement this new common contract. > > Why do you need this contract? What benefit do you gain? > >> The other thing we discussed was integrating XML overrides into the >> indexing process since quite a few places where Jandex gets used would >> need this. And since you worked on that in the metamodel codebase, was >> hoping to get your feedback as to whether you thought it would be >> possible to integrate XML overrides into this process up front. > > IMO it does not matter so much whether you do the overrides before or > after > annotation processing. It kind of makes sense to do it afterwards, > because the > xml configuration normally overrides existing annotations, so > replacing an AnnotationInstance > in the annotation based index with a pseudo AnnotationInstance > reflecting xml > configuration seems "natural". > > The problem of course is that a Jandex index is immutable and I > cannot just replace/modify > an AnnotationInstance. For that reason you have to a lot of > collection iterations/copies. > > If one wanted to improve on this I could imagine building some sort > of OverrideIndex up front > containing the pseudo AnnotationInstances from the XML configuration. > This OverrideIndex > would be generic and could be part of Jandex to be used by other > projects. This index could be > passed prior to Jandex prior to the annotation discovery phase. For > every annotation the discovery > index could query the OverrideIndex whether an override exists for a > given annotation. If so this > override would be added. The benefit of this approach is of course > that I don't have to build > multiple indexes. this can be done with CompositeIndex (though it doesn't exist yet), so we have two index, one is from annotation scan the other we manually build from xml parsing, and in the CompositeIndex we handle the override strategy. > > One thing I am not sure about is how to handle changes in xml > configuration files. How do we know > that we have to discard an index stored on the file system. Not even > quite sure how AS handles changed > classes (there might be some checksumming going on, not sure). > > On the ORM side we are currently not saving the index to disk. Right > now we create a new index and add > explicitly the classes/packages the user specifies via the > configuration. Once this processing is complete > we do the xml overrides and get what Steve calls the CompositeIndex. > After the configuration phase is > over the index is discarded. > > In the long run it would be good if we could store the index and load > it on startup. > > My 0.02$, > Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev ------------------------- Best Regards, Strong Liu <stliu at hibernate.org <http://hibernate.org/>> http://about.me/stliu/bio

On 07/17/2012 04:58 AM, Hardy Ferentschik wrote: > > On Jul 16, 2012, at 9:06 PM, Steve Ebersole wrote: > >> One such point of discussion was a common interface for "Index". >> Unfortunately the name Index is already taken as in the main Jandex >> class. So we came up with some other names. For this work I went ahead >> with the name 'IndexResult' for that common contract (interface). >> Anyway, no matter the name, eventually both Index and that new >> CompositeIndex would both implement this new common contract. > > Why do you need this contract? What benefit do you gain? We want to re-use what JBoss AS would hand us, so we need an interface. The issue is that AS creates an Index per module, it then aggregates them together in a "composite index". Hibernate would need access to this aggregation/composition. AS already has this class. We are just applying a common contract over the 2. It also allows wrapping the "index" in annotation overrides, if thats the route we end up wanting/needing to go.

>> The other thing we discussed was integrating XML overrides into the >> indexing process since quite a few places where Jandex gets used would >> need this. And since you worked on that in the metamodel codebase, was >> hoping to get your feedback as to whether you thought it would be >> possible to integrate XML overrides into this process up front. > > IMO it does not matter so much whether you do the overrides before or after > annotation processing. It kind of makes sense to do it afterwards, because the > xml configuration normally overrides existing annotations, so replacing an AnnotationInstance > in the annotation based index with a pseudo AnnotationInstance reflecting xml > configuration seems "natural". > > The problem of course is that a Jandex index is immutable and I cannot just replace/modify > an AnnotationInstance. For that reason you have to a lot of collection iterations/copies. You just hit on one of the exact reasons to do this. Not that we want an index to be mutable. I think having them immutable is probably the right choice. But having additional collections hanging around in memory, not to mention the multiple processing of those collections is what would be good to avoid.

> If one wanted to improve on this I could imagine building some sort of OverrideIndex up front > containing the pseudo AnnotationInstances from the XML configuration. This OverrideIndex > would be generic and could be part of Jandex to be used by other projects. This index could be > passed prior to Jandex prior to the annotation discovery phase. For every annotation the discovery > index could query the OverrideIndex whether an override exists for a given annotation. If so this > override would be added. The benefit of this approach is of course that I don't have to build > multiple indexes. I think a confusion might be that I am not asking to be able to hand Jandex an XML file and expecting it to be able to "figure out" how XML overriding works as it reads annotation information. No, there would need to be some sort of SPI between Jandex and Hibernate (or other interested libraries) that directed Jandex how/if/when to apply an override.

> That's what I have in mind as well. Basically what I tried to outline. Ok, but one point is that having this OverrideIndex may not be enough. As Strong points out, a consideration here is the concept of <metadata-complete/>. Consider a class with no annotations, that is mapped via orm.xml…

I don't see there is a general way to integrate xml override into jandex, I think it is a very domain specific issue. and the "override" has lots of different requirements, for example "metadata-complete" org.hibernate.metamodel.internal.source.annotations.xml.mocker.IndexBuilder#mappingMetadataComplete -- Strong Liu Sent with Sparrow <http://www.sparrowmailapp.com/?sig> On Tuesday, July 17, 2012 at 3:06 AM, Steve Ebersole wrote: > Strong, I forgot to mention that Jason completely agrees that changes to > Jandex are needed. I agreed to prototype some of the things he and I > discussed specifically in this code base and hand them back to him for > integration back into the next rev of Jandex. > > One such point of discussion was a common interface for "Index". > Unfortunately the name Index is already taken as in the main Jandex > class. So we came up with some other names. For this work I went ahead > with the name 'IndexResult' for that common contract (interface). > Anyway, no matter the name, eventually both Index and that new > CompositeIndex would both implement this new common contract. > > The other thing we discussed was integrating XML overrides into the > indexing process since quite a few places where Jandex gets used would > need this. And since you worked on that in the metamodel codebase, was > hoping to get your feedback as to whether you thought it would be > possible to integrate XML overrides into this process up front. And if > so, how you thought it might be best to approach that. > > > On 07/16/2012 12:25 PM, Steve Ebersole wrote: >> Not sure what happened. Maybe I just forgot to upload? Anyway, it is >> there now. >> >> On Mon 16 Jul 2012 09:39:04 AM CDT, Steve Ebersole wrote: >>> Hmmm.. let me check... >>> >>> On Mon 16 Jul 2012 08:45:48 AM CDT, Hardy Ferentschik wrote: >>>> Hi, >>>> >>>> >>>>> It also contains some major refactorings: >>>>> 1) removal of Ejb3Configuration in preference of the new 2-phase >>>>> bootstrap approach of Bootstrap/EntityManagerFactoryBuilder. >>>> >>>> sounds good >>>> >>>>> 2) I renamed o.h.ejb to o.h.jpa. >>>> >>>> +1 jpa is much more concise >>>> >>>>> Let me know if you see any problems… >>>> >>>> it seems you latest code depends on a Draft-6b which is not deployed >>>> to the repository. I can only see Daft-6. >>>> >>>> Could not resolve all dependencies for configuration >>>> ':hibernate-core:compile'. >>>>> Could not find group:org.hibernate.javax.persistence, >>>>> module:hibernate-jpa-2.1-api, version:1.0.0.Draft-6b. >>>> Required by: >>>> org.hibernate:hibernate-core:4.1.5-SNAPSHOT >>>> >>>> --Hardy >>> >>> -- >>> steve(a)hibernate.org <mailto:steve@hibernate.org> >>> http://hibernate.org >> >> -- >> steve(a)hibernate.org <mailto:steve@hibernate.org> >> http://hibernate.org > > -- > steve(a)hibernate.org <mailto:steve@hibernate.org> > http://hibernate.org > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev