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