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