I don't care about who auto-registers it, Annotations is fine, core
will probably do too; I just ask to make sure it's instantiated and
initialized only once and then registered to each event using the same
FullTextIndexEventListener instance.
When using org.hibernate.search.event.EventListenerRegister it is the
same instance which gets registered, but it's initialized several
times in an unknown order; while when registered by configuration
there are more instances and they share the SearchFactoryImpl by using
the contextholder trick.
If you could mandate the order in core, or avoid multiple
initializations, we can remove the ContextHolder. Or maybe it can be
done in Search if I could know for sure if it's safe to ignore
multiple initializations (ignoring subsequent initializations after
the first one).
Or you could just create a SearchFactoryImpl once, and then give it to
each listener indipendently from how they are setup.
Sanne
2010/2/3 Emmanuel Bernard <emmanuel(a)hibernate.org>:
So what you want is essentially to move the registering code from
annotations to core, right?
On 2 févr. 2010, at 14:34, Sanne Grinovero wrote:
> right it's a separate concern, so I'll change the subject, but it
> would still be very nice to change this before the release of
> Hiberante Core 3.5
> so we can finally remove this Contextholder and cleanup that part.
> If you do it later we need to keep it around to be compatible.. but as
> you're breaking compatibility now it looks like a good moment to do
> this, so that Search 3.2 would be clean and depending on core 3.5
> only.
> We could also remove all documentation about listeners, as the
> hand-configured way would never be needed.
>
> Sanne
>
> 2010/2/2 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> That's a separate concern if I understand you correctly.
>> If I summarize, you want to be able to tell core to initialize one instance of a
listener across a set of events provided the listener implements all the required
interfaces.
>>
>> On 2 févr. 2010, at 00:27, Sanne Grinovero wrote:
>>
>>> Didn't follow the full discussion, but this looks like a good moment
>>> to rise a flag
>>> about HSEARCH-314: I'm still not sure if this bug is real or not,
>>> but the ContextHolder could now be removed altogether, removing any
>>> doubt about memory leaks:
>>>
>>> as core registers the listener by reflection if Search is found, and
>>> this Search will need at least this version of Hibernate, registering
>>> the listeners by configuration doesn't make sense anymore.
>>> Also older versions of Search aren't compatible (BTW, what about
>>> changing the eventlistener name and throw an exception if older
>>> incompatible version is found?)
>>> If you remove the ContextHolder and make sure the eventlistener is
>>> initialized only once it should be fine. Core should just create a
>>> single instance of the Search listener for all events, this is already
>>> the case afaik.
>>>
>>> Sanne
>>>
>>> 2010/2/1 Steve Ebersole <steve(a)hibernate.org>:
>>>> For Search afaict as you mentioned listeners will be the touchpoint
>>>> here. So it depends on what is accessible to the listeners.
>>>>
>>>> At some point this just needs to be a best effort.
>>>>
>>>>
>>>> On Mon, 2010-02-01 at 18:42 +0100, Emmanuel Bernard wrote:
>>>>> Hardy,
>>>>> How would it work for say a DirectoryProvider in Hibernate search
(which is a plugin of HSearch which itself is a plugin of Core in a way - listener).
>>>>>
>>>>> Remember we have the hibernate.search.default.[customproperty]
category and the hibernate.search.[indexname].[customproperty] category. What would the
the impl of PropertyConsumer#collectConsumedProperties like for Hibernate Search?
>>>>>
>>>>>
>>>>> On 1 févr. 2010, at 16:28, Hardy Ferentschik wrote:
>>>>>
>>>>>> The pull approach via an additional PropertyConsumer interface
works for me.
>>>>>> It seems to be a good trade-off. Least invasive while still
getting some order
>>>>>> into the properties.
>>>>>>
>>>>>> --Hardy
>>>>>>
>>>>>>
>>>>>> On Mon, 01 Feb 2010 12:14:02 -0300, Steve Ebersole
<steve(a)hibernate.org> wrote:
>>>>>>
>>>>>>> On Mon, 2010-02-01 at 09:49 +0100, Emmanuel Bernard wrote:
>>>>>>>> Also "plugins" can make use of the general
availability of properties.
>>>>>>>> For example Hibernate Search reads everything under
hibernate.search (and it's not a limited set of property names). Likewise, HSearch
extensions can use whatever property name they want to configure say the custom backend or
the directory providers (either custom or even one of the system properties).
>>>>>>>
>>>>>>> The main use case I was keeping in mind along the way was
caching. I know in the JBC and Infinispan integrations they added the ability to read a
lot of config information from our properties.
>>>>>>>
>>>>>>> As long as it is something configured by the Configuration
->
>>>>>>> Settings/SessionFactory process or the something is known to
>>>>>>> SessionFactory at the end of its init it is workable. For
example, I
>>>>>>> imagine Validator would be easy to tie in here because of the
listeners;
>>>>>>> they are known to the SessionFactory. Not so sure about
Search, it
>>>>>>> registers listeners too so maybe its ok.
>>>>>>>
>>>>>>> The first question is whether we want a push or pull (from
perspective
>>>>>>> of the things being configured) model here. For example,
would the
>>>>>>> ConnectionProvider tell SessionFactory about the properties
it consumed
>>>>>>> (push)? Or would the SessionFactory ask the
ConnectionProvider for that
>>>>>>> info (pull)?
>>>>>>>
>>>>>>> The pull approach has the advantage of being the least
trade-off . We
>>>>>>> could add an optional interface "PropertyConsumer"
that things can
>>>>>>> choose to implement. If they do, the method would be
something like
>>>>>>> "collectConsumedProperties(Map copy)"; they would
put all the property
>>>>>>> keys/values into the given map.
>>>>>>>
>>>>>>> Another potential "pull" approach is to not pass
around j.u.Properties
>>>>>>> into these things to configure themselves, but to instead
wrap that in a
>>>>>>> class that journals the key/values as they are requested.
That is a bit
>>>>>>> more invasive though as it would mean changing quite a few
contracts,
>>>>>>> some of which are implemented by classes outside our
control.
>>>>>>>
>>>>>>> In the "push" strategy, the things configuring
themselves somehow push
>>>>>>> which properties (key/value) they are consuming. Much like
the second
>>>>>>> pull-approach, this is pretty invasive because we would need
to pass in
>>>>>>> the mechanism for these "configurables" to report
back which properties
>>>>>>> they are consuming. Not to mention its tedious.
>>>>>>>
>>>>>>> Long term I like the second pull approach. However, I
personally think
>>>>>>> it is too disruptive in the short term and that we should use
the first
>>>>>>> pull approach for now.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Steve Ebersole <steve(a)hibernate.org>
>>>>
Hibernate.org
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>