[hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

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 at 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?
>