[hibernate-dev] JPA 2.1 progress

[Steve Ebersole]

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.


> 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.

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.

-- 
steve at hibernate.org
http://hibernate.org