[hibernate-dev] Jandex, scanning and discovery

[Steve Ebersole]

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.




On Fri, Apr 25, 2014 at 11:57 AM, Steve Ebersole <steve at hibernate.org>wrote:

> So here is what I propose more concretely...
>
> As a refresher, there are a few main characters:
> * Scanner - coordinates the scanning effort
> * PersistenceUnitDescriptor - provides access to needed PU information
> * ScanOptions - a few booleans to control processing within Scanner
> * ArchiveDescriptorFactory - essentially acts as a "URL interpreter" (this
> is one of the main customization points in the new scanning code)
> * ArchiveDescriptor / ArchiveEntry - describe the parts of the archive we
> want to look at
> * ArchiveEntryHandler - the main visitation contract for inspecting
> ArchiveEntry
>
> ArchiveEntryHandler is the place where the collection happens.  There are
> ArchiveEntryHandler specializations for each type of archive entry: class
> file, package-info file, etc.  The ArchiveEntryHandler for class files is
> really the only place that needs a change (to add to a supplied Jandex
> Indexer).  However, I think some other changes are worthwhile.  First,
> relying on PersistenceUnitDescriptor ties this to building of an EMF.  With
> a simple tweak, we could make this usable in "native SF" building also.
>  And given the above stated importance on Jandex, I think this is
> worthwhile change.
>
> I wanted to go over the specifics because this is an SPI, and because I
> know at least one customization of this SPI for integration : WildFly,
> which hooks in mainly to deal with its VFS URL handling.  I think WildFly
> usage should be safe from these changes.
>
>
>
> On Thu, Apr 24, 2014 at 4:34 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:
>
>>
>> On 24 Jan 2014, at 23:25, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > I'd like to suggest one change in scanning to support this as well.
>>  Currently when the Scanner finds a Class, or package-info, etc it
>> immediately checks the "options" to see if this entry can be accepted
>> (essentially according to the PU).  I'd rather change this up so that the
>> collector is notified as soon as we find an entry.  This would allow the
>> collector to index the entry in Jandex no matter what and to decide what
>> else to do with it (add it list of managed classes, etc).
>>
>> +1, as you say, I think we get more benefit out of the Jandex index if we
>> index all entries/classes.
>>
>> —Hardy
>>
>>
>