Re: [hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection
I can't speak to Searchs or Validators use specifically, but Jandex is
usable outside of WildFly. I know this through initially using Jandex on
that metamodel work. Outside of WildFly, rather than being handed an index
you would build an index. Pretty easy. See in-line wrt some of your
specific requirements.
On Tue, Dec 2, 2014 at 7:13 AM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
It looks awesome! but to be able to use it we also need to take
these
requirements in consideration:
- users running in different containers than WildFly
See above.
- users not running in any container at all
See above.
- Hibernate Search integrators which are not based on ORM: running
in
WildFly but not having the benefit of an EntityManager based bootstrap
where the container can "inject" a reference to the index; how do we
get the index from the application server there?
Actually this is "problem" for non-JPA ORM use in WildFly too. The passing
of the Jandex index is part of the JPA bootstrap process. I do not know of
a way for a component to ask for a Jandex index itself aside from some code
in WildFly pushing that to you.
- integrators running anywhere (WildFly but not only) which today
need to add new entity types "on the fly" at runtime (after
the
bootstrap was completed).
I am not fully grokking what you are saying here. You mention it below
too. I think you are saying something like what Envers does: after all ORM
mappings are known, Envers wants to add additional mappings (its versioned
entities). Of course Envers is a bit different in that the additional
metadata it adds is not annotation based, but xml based. But "expanding" a
Jandex index is pretty easy because they can be composed/aggregated.
I guess that's possible?
We could also change one point dramatically: with Infinispan Query the
reason for it to need adding new types "on the fly" is just because
there is no reasonable solution for a full annotation scanning. But
having this we might be able to simplify some code in Search by
actually expecting to have a comprehensive list of types at bootstrap
through Jandex, then we can remove some of the code to do "on the fly"
type registration.
I'm saying that we could remove some of the code because with
dynamic
types coming, we'll still want to make it possible to define new types
dynamically.. so we wouldn't be able to remove all complexity but it
still seems a good progress.
Actually, one of Jandex's huge strengths is exactly this use case. The
ability to "scan" for annotations. For example, ORM couldask Jandex for
all uses of the @Entity annotation as a means to discover all annotated
entities. Maybe I am misinterpreting your "no reasonable solution for a
full annotation scanning" comment. Perhaps you mean in the
non-WildFly-handed index case? In that non-WildFly-handed index case there
is a question as to how you know what files to add to the index. Ideally,
Jandex would cover the entire available ClassLoader.