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
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:
> 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.
>> On Mon, 01 Feb 2010 12:14:02 -0300, Steve Ebersole
>>> On Mon, 2010-02-01 at 09:49 +0100, Emmanuel Bernard
>>>> 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
>>> Settings/SessionFactory process or the something is known
>>> SessionFactory at the end of its init it is workable.
For example, I
>>> imagine Validator would be easy to tie in here because of
>>> they are known to the SessionFactory. Not so sure about
>>> registers listeners too so maybe its ok.
>>> The first question is whether we want a push or pull
>>> of the things being configured) model here. For example,
>>> 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
>>> "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
>>> some of which are implemented by classes outside our
>>> 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
>>> it is too disruptive in the short term and that we should
use the first
>>> pull approach for now.
Steve Ebersole &lt;steve(a)hibernate.org>