[hibernate-dev] Jandex 2.0 Beta - Java 8 Type Annotations, Generics, & Offline Reflection
Steve Ebersole
steve at hibernate.org
Tue Dec 2 10:06:00 EST 2014
Forgot to mention, that it is even conceivable to have an optional
build-time step that would allow users to pre-build the Jandex index for
even faster startup in outside-of-WildFly use cases. A serialized form if
you will. I want to investigate that in ORM.
On Tue, Dec 2, 2014 at 9:03 AM, Steve Ebersole <steve at hibernate.org> wrote:
> 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.
>
>
More information about the hibernate-dev
mailing list