Hi Scott,


On 5 August 2014 17:45, Scott Marlow <smarlow@redhat.com> wrote:
Thanks for the complements Andrej!  :-)

Sanne, please see in-line below.


On 08/05/2014 09:49 AM, Sanne Grinovero wrote:
Hi Andrej,
that's an excellent point.

I also don't want to make it harder for users to play with the latest
versions we'll be releasing - normally at a higher pace than WildFly.

I'm not sure that you need to sync up with WildFly as much as the Hibernate ORM project.  For example,



I guess I'll need learn more about writing a subsystem to make sure
these options are covered.

If Hibernate Search is a part of the Hibernate ORM module, like Envers is, that could make integration easy enough for Hibernate Search and users that want to package Hibernate ORM with their application.  They either also include Hibernate Search or not.  If applications include Hibernate ORM but no Hibernate Search, they can't use Hibernate Search.


​There are no problems for people packaging it as long as they don't enable conflicting modules, my point is that I want to encourage the modules usage to take advantage of its many benefits. Not least, that you don't need to deploy many jars which are already included in the server.

​​
A bigger problem though is that bundling Hibernate Search with the application, likely means that the application server version of Infinispan (already configured and ready to work with clustering), will not be usable.

<tangent>
Another related issue is that Hibernate 3.x depends on an older version of Infinispan, so when Hibernate 3.x is used on WildFly, clustering of the second level cache will not work (even when Hibernate 3.x is used as a wildfly/modules (static) module).  The same will occur with other versions of Hibernate as well.

In theory, we could externalize clustering integration to be external to the Hibernate ORM codebase (in Jipijapa).  I've done some experimentation with that but not too far (more for EclipseLink/OpenJpa 2lc clustering but we could see some benefit to Hibernate also).
</tangent>

Hibernate Search integrates with the latest versions of ORM and Infinispan, Hibernate 3 is unrelated to this?​
The versions of Hibernate Search libraries included in WildFly are released and tested specifically to be fully aligned with the other versions of libraries in WildFly: keeps the modules lean and avoids lots of trouble. No idea why you think I might depend on years old versions :)
Also Search doesn't depend on clustering, it's some code of clustering which depends on it (so the other way around), but via this path of the dependency graph you are completely isolated from ORM (the Hibernate Search Engine module does NOT depend on Hibernate ORM).

What I'd like is to have this functionality exposed to deployments who need it without them having to reconfigure/enable modules, but I certainly don't want to expose the clustering dependencies as well.
I understand now that I need to learn about the subsystems, got it :)

Thanks for all the ideas, I'll certainly ping you to learn about subsystem development.

Sanne

 


Scott


Thanks all,
Sanne

On 4 August 2014 20:43, Andrej Golovnin <golovnin@gmx.net> wrote:
Hi Sanne,

I see no reasons to not enable it by default, following the same
activation rules of other Hibernate dependencies: it's very
conservative about not auto-enabling itself when not needed.


It is OK as long as it will be still possible to bundle Hibernate Search
within an application and Hibernate would use the bundled version of
Hibernate Search.

Not all users want to use Hibernate and Hibernate Search,
which are delivered with WildFly.

For Hibernate we have a perfect solution developed by Scott, which
allows WildFly to use Hibernate packaged inside of an application.
At this place a big thanks to Scott for this wonderful solution! It works great!
The same should be possible with Hibernate Search.

Best regards,
Andrej Golovnin
_______________________________________________