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
