[hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection

[Steve Ebersole]

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