Re: [hibernate-dev] EMF / EM properties

The 'know in advance' approach is exactly what I was trying to avoid. I guess that is another option I forgot on that list It's not the I want to implement (way too tedious). -- Sent from my Palm Pre steve(a)hibernate.org http://hibernate.orgEmmanuel Bernard wrote: Yep. Provided HSearch does not know in advance what properties are required by its plugins, I was wondering how that would work. That's why I asked Hardy for an implementation example as he seemed to have understood. On 1 févr. 2010, at 20:52, Steve Ebersole wrote: > 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 >