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 <st...@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 <sa...@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. > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
