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. 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
