[hibernate-dev] Jandex, scanning and discovery

[Steve Ebersole]

FYI, I created a Pull Request[1] to discuss these changes if anyone was
interested.  If not I'll apply this later in the week.  The commits
incorporate some other concepts such as some changes to "user directed
logging" I discussed in hibernate-dev emails.  I have added some line
comments at important stuff.

[1] https://github.com/hibernate/hibernate-orm/pull/737


On Wed, Apr 30, 2014 at 12:30 PM, Steve Ebersole <steve at hibernate.org>wrote:

> I am contemplating something very drastic here.  The back story is that we
> end up needing to index stuff from 2 places: the
> EntityManagerFactoryBuilder and again from MetadataBuildingProcess (part of
> Binder processing).  The indexing from EntityManagerFactoryBuilder happens
> just during JPA bootstrapping.  The indexing from MetadataBuildingProcess
> happens for both.  The difficulty this presents is that we end up needing
> to pass the same Indexer to both.
>
> What I started thinking would be better is to perform all the indexing
> from MetadataBuildingProcess.  But given the idea to perform a full index
> of all classes as we scan, that would also mean moving scanning
> into MetadataBuildingProcess.  Which I do not think is a bad idea (in fact
> in isolation I think its a great idea).  My concern is more that atm this
> is exposed as an SPI from HEM under the o.h.jpa package.  I could just move
> the package in total to hibernate-core, I'm just ecstatic about a o.h.jpa
> package being used for stuff that is (no longer) JPA specific.  But maybe
> that's ok i the short term?  Could also do a "ghost package" concept
> (deprecate old package and have it extend from new package) to help
> integrators in the short term.
>
> I have already made scanning not dependent upon the JPA spis.  Used to be
> that scanning operated on the PersistenceUnitDescriptor.  But really we
> just need a small subset of that information to actually perform scanning:
> 1) what is the root url?
> 2) what are the non-root urls?
>
> Not really needed for scanning, but needed in collecting the scan results:
> 1) list of explicitly provided class names
> 2) list of explicitly provided mapping file names
>
> So bottom line... none of this is JPA specific any more.  Moving scanning
> to MetadataBuildingProcess allows us to centralize indexing in one place.
>
> Thoughts?
>
>
> On Mon, Apr 28, 2014 at 1:09 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:
>
>>
>> On 28 Jan 2014, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > Almost done with this.  We are much more aggressive about indexing
>> stuff into Jandex now (which is a good thing) when we are not handed a
>> Jandex Index.
>> >
>> > However, this does mean we need to be more careful in the case of JPA
>> and exclude-non-listed-classes.  ATM we drive annotations based on Jandex
>> (aka, the classes known to Jandex).  However, if we know index classes that
>> should not be used as entities, etc (because of exclude-non-listed-classes)
>> we are breaking the JPA spec.  To this end, I suggest that scanning:
>> > 1) Index everything
>> > 2) Keep a running tab of "allowable managed classes and packages".
>> >
>> > Later, when beginning interpretation of annotations (via Jandex) we can
>> cross-reference that with the list of allowable managed classes.  Currently
>> we do:
>> >
>> > for ( ClassInfo classInfo :
>> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>> >     // use them all...
>> > }
>> >
>> >
>> > What I am suggesting is:
>> >
>> > interface ManagedClassFilter {
>> >     public boolean allowAsManagedClass(ClassInfo classInfo);
>> > }
>> >
>> > for ( ClassInfo classInfo :
>> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>> >     if ( !managedClassFiler.allowAsManagedClass( classInfo ) ) {
>> >         continue;
>> >     }
>> > }
>> >
>> > Further, rather than maintaining potentially large lists of allowable
>> class and package names, I'd also suggest we recognize the cases when we
>> have open-ended discovery in play and simply use an "all inclusive"
>> strategy.
>>
>> sounds good.
>
>
>