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 wrote:
>
> On 28 Jan 2014, at 17:20, Steve Ebersole 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
