Here is the basic idea: http://pastebin.com/m6add9d4b
Rather than passing around Properties, we'd pass somethign like that around. Then we'd use its "getConsumedProperties". On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote: > That's the point Hardy, the list of consumed properties is not known in > advance in Hibernate search. Or is the plan get core pass all the raw > Properties and HSearch return the list of properties it really wants? In > which case it will return all of them to implement our current approach. > > I guess the point is that I am lost and don't see how (my understanding of) > the pull second option can work for Search. > > On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote: > > > For the Hibernate Search case I could imagine to implement Steve's second > > pull > > approach. Search already defines an interface SearchConfiguration which > > delegates the > > access to the underlying Configuration properties. It should be easy to > > implement some > > sort of journaling to keep track which properties Search consumes. > > > > If we can keep track of the consumes properties we should be able to report > > this back > > into Core via the PropertyConsumer#collectConsumedProperties approach. > > > > WDYT? > > > > --Hardy > > > > On Tue, 02 Feb 2010 09:54:57 -0300, Steve Ebersole <st...@hibernate.org> > > wrote: > > > >> 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 > >> st...@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 > >>>>> <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 > >> > >>> > >> > >> > >> > >> > > > -- Steve Ebersole <st...@hibernate.org> Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
