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
> 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
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
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
passed prior to Jandex prior to the annotation discovery phase. For every annotation the
index could query the OverrideIndex whether an override exists for a given annotation. If
override would be added. The benefit of this approach is of course that I don't have
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.
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
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.
Not sure whether AS does this caching. But if we wanted to go this
route in cases where we are not handed a Jandex instance, then I think
we have some great lessons to learn from git and gradle in terms of
leveraging hashes to determine whether we need to rebuild a Jandex
instance. However, I think we should probably *not* do this by default.