Re: [hibernate-dev] Jandex, scanning and discovery
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(a)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(a)hibernate.org>wrote:
>
> On 24 Jan 2014, at 23:25, Steve Ebersole <steve(a)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
>
>