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