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 <st...@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 <ha...@hibernate.org>wrote:
>
>>
>> On 24 Jan 2014, at 23:25, Steve Ebersole <st...@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
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
