Hi Scott,
On 5 August 2014 17:45, Scott Marlow <smarlow(a)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(a)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
>>
> _______________________________________________
>
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>