[hibernate-dev] Jandex, scanning and discovery

[Steve Ebersole]

I have this working, but given the current scope of Scanner it is
unfortunately of limited use.  That is, currently it only works when using
JPA boostrapping (technically, whenever you use the
EntityManagerFactoryBuilder).

Given how central we are making Jandex in this scheme, I think its
worthwhile to consider ways to make it work in "native Hibernate"
bootstrapping as well.  Maybe this is as simple as allowing the user to
specify a base url for scanning.

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).

WDYT?



On Mon, Apr 21, 2014 at 2:04 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 21 Jan 2014, at 16:48, Steve Ebersole <steve at hibernate.org> wrote:
>
> > As Brett finishes up the "unified schema" work I wanted to start
> discussion
> > about some simplifications that could/should come from that.
>
> I really like where all these work is going. I hope the unification will
> work
>
> > As I said, in the cases we are not handed a Jandex Index we need to build
> > one.  Currently this is a tedious process handled by manually indexing
> all
> > known classes (known from a few different sources).  But this need to
> know
> > the classes to index them is problematic.
>
> +1 In this area we had (or maybe still have some failing tests). The old
> code
> used to take used to take the configured classes from the config, build
> the hierarchy and process all classes in the hierarchy. So it would for
> example
> “discover” a @MappedSuperclass even so the class was not explicitly listed
> in the the persistence unit / hibernate config.
>
> When doing the initial work on Jandex I assumed that all annotated classes
> are in the Jandex index. This, however, requires that all annotated
> classes would
> need to be explicitly configured. To keep backwards compatibility  we
> added some
> code which would also do the processing of the hierarchy.
>
> > Which got me to thinking that it sure would be nice to tie this in to the
> > scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already
> such
> > that as we walk the "archive" we automatically add classes we encounter
> to
> > the Index.  I'd actually add things to the Index whether or not they are
> > supposed to be managed classes (exclude-unlisted-classes).
>
> +1 Sounds like a good idea and also solves the problem described above in
> a nice
> way.
>
> > There are lots of benefits to this.  And not just to ORM, provided we
> start
> > sharing the Jandex with Search (etc) as we have discussed.
>
> +1 This would be very useful for HSEARCH-1213 where the aim is to switch
> to Jandex.
>
> >  This better
> > ensures that all needed classes are available in the Index.  This allows
> > better discovery of "ancillary" classes via annotation.  Etc…
>
> +1
>
> > I think the solution is to expose all the 'persistence-unit-defaults'
> > values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab
> > them from there.
>
> +1
>
> —Hardy