12:58 p.m.
Currently users wishing for Search super-powers in their Hibernate
applications need to enable the module explicitly.
This seems to be rather annoying, and we have questions like this one:
- https://community.jboss.org/thread/243346
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.
May I open such a feature request? Happy to try the patching myself.
Sanne
3:29 p.m.
On 08/01/2014 06:58 AM, Sanne Grinovero wrote:
Currently users wishing for Search super-powers in their Hibernate
applications need to enable the module explicitly.
This seems to be rather annoying, and we have questions like this one:
- https://community.jboss.org/thread/243346
I responded to this particular question, which was how to enable a
module to be available from all deployments. That really has nothing to
do with Hibernate Search.
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.
Are you asking if its possible to have Hibernate Search deployment code
that detects use of Hibernate Search (perhaps after noticing use of some
Hibernate Search annotation) and adds a deployment dependency on some
Hibernate search module as a result?
May I open such a feature request? Happy to try the patching myself.
Not sure. I wonder if it would be better to have a separate Hibernate
Search profile for WildFly that includes deployment code to
automatically add application dependencies on Hibernate Search.
For this to work, I think that Infinispan's dependency on Hibernate
Search would need to not cause clustering/2lc failures when the
Hibernate Search module profile is not installed.
I think this would be nice as it would lay the groundwork for Search to
be separate (depending on how you feel about that). :)
Sanne
1:42 a.m.
On 1 August 2014 14:29, Scott Marlow <smarlow(a)redhat.com> wrote:
On 08/01/2014 06:58 AM, Sanne Grinovero wrote:
>
> Currently users wishing for Search super-powers in their Hibernate
> applications need to enable the module explicitly.
>
> This seems to be rather annoying, and we have questions like this one:
> - https://community.jboss.org/thread/243346
I responded to this particular question, which was how to enable a module to
be available from all deployments. That really has nothing to do with
Hibernate Search.
Thanks!
But still that post is yet-another sign as I commonly see on Hibernate
forums of people struggling to enable it: people migrating from other
systems are used to see Search automatically enable itself without
need of further hassle.
Also people tend to not perceive it as an independent thing from the
main Hibernate ORM, so when it doesn't work the modules system is the
last thing they think to check.
> 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.
Are you asking if its possible to have Hibernate Search deployment code that
detects use of Hibernate Search (perhaps after noticing use of some
Hibernate Search annotation) and adds a deployment dependency on some
Hibernate search module as a result?
For user experience it shouldn't be different than Hibernate Envers.
Implementation wise it's probably going to be slightly different, for
example we have an independent versioning from ORM.
I have no strong opinion on how we should do it, a simple solution
would be to merge it with Hibernate ORM, like you did for Envers: it's
a single jar, and having slot "main" the version mismatch doesn't
matter.
Alternatively the JPA deployer could add it to the user classpath like
it does with the one for Hibernate ORM, but keeping the modules
separate.
I see detection as a nice to have: since it's functionally redundant
with the detection performed by the code in Hibernate, we can tackle
that at a second time.
>
> May I open such a feature request? Happy to try the patching myself.
Not sure. I wonder if it would be better to have a separate Hibernate
Search profile for WildFly that includes deployment code to automatically
add application dependencies on Hibernate Search.
A profile for a single jar?
We only need the one in the (existing) module
"org.hibernate.search.orm": very similar to Envers, it was simply a
mistake to not expose it by default from the beginning.
For this to work, I think that Infinispan's dependency on Hibernate Search
would need to not cause clustering/2lc failures when the Hibernate Search
module profile is not installed.
True, but that has been taken care of ;-) it's already nicely split in
different JBoss Modules, and Infinispan depends on a different module
"org.hibernate.search.engine", shared among the various projects
depending on the engine.
I think this would be nice as it would lay the groundwork for Search to be
separate (depending on how you feel about that). :)
I agree, but it's a different aspect to get the dependency modularity
right, and making sure the users don't get confused.
I think the modules are correct already, now I'd like to make it easy to use.
Sanne
3:34 p.m.
On 8/1/14, 5:58 AM, Sanne Grinovero wrote:
Currently users wishing for Search super-powers in their Hibernate
applications need to enable the module explicitly.
This seems to be rather annoying, and we have questions like this one:
- https://community.jboss.org/thread/243346
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.
May I open such a feature request? Happy to try the patching myself.
Would there be some configuration mechanism for users to turn this off?
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:49 a.m.
On 1 August 2014 14:34, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
On 8/1/14, 5:58 AM, Sanne Grinovero wrote:
> Currently users wishing for Search super-powers in their Hibernate
> applications need to enable the module explicitly.
>
> This seems to be rather annoying, and we have questions like this one:
> - https://community.jboss.org/thread/243346
>
> 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.
>
> May I open such a feature request? Happy to try the patching myself.
>
Would there be some configuration mechanism for users to turn this off?
Yes, just set "hibernate.search.autoregister_listeners" to "false".
This property is read as any other Hibernate / JPA configuration
properties, so could be set globally at boot of the JVM or in the
scope of a specific Hibernate instance.
But that's just an extreme emergency button, as it won't trigger if
entities are not marked with Search specific annotations.
-- Sanne
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:49 p.m.
This sounds like a perfect valid case for new subsystem
that would handle hibernate-search related stuff.
and could based on some deployment markers enable / add dependent modules
to deployment.
it could also help configure search / ogm via server config :)
On Fri, Aug 1, 2014 at 12:58 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Currently users wishing for Search super-powers in their Hibernate
applications need to enable the module explicitly.
This seems to be rather annoying, and we have questions like this one:
- https://community.jboss.org/thread/243346
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.
May I open such a feature request? Happy to try the patching myself.
Sanne
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:08 a.m.
On 1 August 2014 19:49, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
This sounds like a perfect valid case for new subsystem
that would handle hibernate-search related stuff.
and could based on some deployment markers enable / add dependent modules to
deployment.
it could also help configure search / ogm via server config :)
Excellent idea :)
But I'd prefer to do that in a second step if that's ok: I was hoping
now to make only this minimal usability improvement for WildFly 8.2,
and reserve those more significant improvements for WildFly 9.
-- Sanne
On Fri, Aug 1, 2014 at 12:58 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> Currently users wishing for Search super-powers in their Hibernate
> applications need to enable the module explicitly.
>
> This seems to be rather annoying, and we have questions like this one:
> - https://community.jboss.org/thread/243346
>
> 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.
>
> May I open such a feature request? Happy to try the patching myself.
>
> Sanne
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:43 p.m.
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
3:49 p.m.
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 guess I'll need learn more about writing a subsystem to make sure
these options are covered.
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
6:45 p.m.
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.
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>
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
10:59 p.m.
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
>
>
3543
days inactive
3549
days old
10 comments
5 participants
participants (5)
-
Andrej Golovnin -
Brian Stansberry -
Sanne Grinovero -
Scott Marlow -
Tomaž Cerar