[hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

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 <steve at 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
> steve at 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  
>>>> &lt;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?
>
>>>>>
>
>>>>
>
>>>
>
>> --
>
>> Steve Ebersole &lt;steve at hibernate.org>
>
>> Hibernate.org
>
>>
>
>
>
>