Re: [hibernate-dev] JPA 2.1 progress

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