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 <st...@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 <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
