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(a)hibernate.org>wrote:
On 21 Jan 2014, at 16:48, Steve Ebersole <steve(a)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