[hibernate-dev] Jandex, scanning and discovery
steve at hibernate.org
Mon Apr 21 10:48:00 EDT 2014
As Brett finishes up the "unified schema" work I wanted to start discussion
about some simplifications that could/should come from that.
Jandex, scanning and discovery
One of the outcomes of moving to Jandex to process annotations is the
requirement that we have a good Jandex Index available to us. There are 2
parts to this:
1. We need a "baseline Index". This can be a Jandex Index passed to us
(by WildFly, e.g.). But in cases where we are not passed one, we need to
2. We then augment the Index with "virtual annotations" built from XML
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.
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).
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. This better
ensures that all needed classes are available in the Index. This allows
better discovery of "ancillary" classes via annotation. Etc...
Technically this one is not tied to the unified schema work, we could do
this change today. The difference is that the move to the unified schema
means that everything is processed using Jandex, so having that good Index
becomes even more important.
There is one difficulty I see here. Assuming we are to only use
listed-classes, that means classes explicitly listed in the PU *and*
classes listed in XML. Checking that a class is listed in the PU is
simple, but checking whether a class comes from XML before we use it is not
as straightforward. Its not impossible, just another thing to consider.
Applying XML defaults
orm.xsd allows specifying attribute specific defaults. One such default,
e.g., is access. What happens in the current annotation "mocking" is
that the default access is only applied to attributes that are referenced
in the XML. If the XML is used in an "override" way and an attribute is
defined in the entity with annotations but is not mentioned in the XML, the
default access from the XML is not picked up, as it should be (unless the
annotations define a more local explicit access).
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.
-- seems to me there were others I wanted to discuss, but they escape my
mind at the moment ;)
 I think we all dislike the term "mocking" here. I'd like to start
discussing alternatives. I mentioned "augmentating" above, I like that
More information about the hibernate-dev