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 <emman...@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 <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
