On Jul 17, 2012, at 2:42 PM, Steve Ebersole wrote:
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.
Thanks for the info. I was missing this info and it gives "composite index" a
different meaning as well.
In the composite index is there a way to only query for annotation of a given module? Say
we get a composite index
and are supposed to build the configuration. In our code we can just get for example all
named queries by getting the corresponding
annotations from the index. If you have a composite index you might have to consider
whether the class hosting the annotation is
part of the persistence unit you are processing.
>> 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.
Sure. I get that.
> 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.
--Hardy