[hibernate-dev] EMF / EM properties

[Steve Ebersole]

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 invasive.  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 at hibernate.org>
Hibernate.org