Re: [hibernate-dev] EMF / EM properties

[Emmanuel Bernard]

That's the point Hardy, the list of consumed properties is not known in advance 
in Hibernate search. Or is the plan get core pass all the raw Properties and 
HSearch return the list of properties it really wants? In which case it will 
return all of them to implement our current approach.

I guess the point is that I am lost and don't see how (my understanding of) the 
pull second option can work for Search.

On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:

> 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  
> 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
>> st...@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 
>  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 

Re: [hibernate-dev] Slight change in the way Search is auto-registered by Annotations

[Emmanuel Bernard]

So what you want is essentially to move the registering code from annotations 
to core, right?
On 2 févr. 2010, at 14:34, Sanne Grinovero wrote:

> right it's a separate concern, so I'll change the subject, but it
> would still be very nice to change this before the release of
> Hiberante Core 3.5
> so we can finally remove this Contextholder and cleanup that part.
> If you do it later we need to keep it around to be compatible.. but as
> you're breaking compatibility now it looks like a good moment to do
> this, so that Search 3.2 would be clean and depending on core 3.5
> only.
> We could also remove all documentation about listeners, as the
> hand-configured way would never be needed.
> 
> Sanne
> 
> 2010/2/2 Emmanuel Bernard :
>> That's a separate concern if I understand you correctly.
>> If I summarize, you want to be able to tell core to initialize one instance 
>> of a listener across a set of events provided the listener implements all 
>> the required interfaces.
>> 
>> On 2 févr. 2010, at 00:27, Sanne Grinovero wrote:
>> 
>>> Didn't follow the full discussion, but this looks like a good moment
>>> to rise a flag
>>> about HSEARCH-314: I'm still not sure if this bug is real or not,
>>> but the ContextHolder could now be removed altogether, removing any
>>> doubt about memory leaks:
>>> 
>>> as core registers the listener by reflection if Search is found, and
>>> this Search will need at least this version of Hibernate, registering
>>> the listeners by configuration doesn't make sense anymore.
>>> Also older versions of Search aren't compatible (BTW, what about
>>> changing the eventlistener name and throw an exception if older
>>> incompatible version is found?)
>>> If you remove the ContextHolder and make sure the eventlistener is
>>> initialized only once it should be fine. Core should just create a
>>> single instance of the Search listener for all events, this is already
>>> the case afaik.
>>> 
>>> Sanne
>>> 
>>> 2010/2/1 Steve Ebersole :
 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  
>> 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.

Re: [hibernate-dev] Slight change in the way Search is auto-registered by Annotations

[Sanne Grinovero]

I don't care about who auto-registers it, Annotations is fine, core
will probably do too; I just ask to make sure it's instantiated and
initialized only once and then registered to each event using the same
FullTextIndexEventListener instance.

When using org.hibernate.search.event.EventListenerRegister it is the
same instance which gets registered, but it's initialized several
times in an unknown order; while when registered by configuration
there are more instances and they share the SearchFactoryImpl by using
the contextholder trick.
If you could mandate the order in core, or avoid multiple
initializations, we can remove the ContextHolder. Or maybe it can be
done in Search if I could know for sure if it's safe to ignore
multiple initializations (ignoring subsequent initializations after
the first one).

Or you could just create a SearchFactoryImpl once, and then give it to
each listener indipendently from how they are setup.

Sanne

2010/2/3 Emmanuel Bernard :
> So what you want is essentially to move the registering code from annotations 
> to core, right?
> On 2 févr. 2010, at 14:34, Sanne Grinovero wrote:
>
>> right it's a separate concern, so I'll change the subject, but it
>> would still be very nice to change this before the release of
>> Hiberante Core 3.5
>> so we can finally remove this Contextholder and cleanup that part.
>> If you do it later we need to keep it around to be compatible.. but as
>> you're breaking compatibility now it looks like a good moment to do
>> this, so that Search 3.2 would be clean and depending on core 3.5
>> only.
>> We could also remove all documentation about listeners, as the
>> hand-configured way would never be needed.
>>
>> Sanne
>>
>> 2010/2/2 Emmanuel Bernard :
>>> That's a separate concern if I understand you correctly.
>>> If I summarize, you want to be able to tell core to initialize one instance 
>>> of a listener across a set of events provided the listener implements all 
>>> the required interfaces.
>>>
>>> On 2 févr. 2010, at 00:27, Sanne Grinovero wrote:
>>>
 Didn't follow the full discussion, but this looks like a good moment
 to rise a flag
 about HSEARCH-314: I'm still not sure if this bug is real or not,
 but the ContextHolder could now be removed altogether, removing any
 doubt about memory leaks:

 as core registers the listener by reflection if Search is found, and
 this Search will need at least this version of Hibernate, registering
 the listeners by configuration doesn't make sense anymore.
 Also older versions of Search aren't compatible (BTW, what about
 changing the eventlistener name and throw an exception if older
 incompatible version is found?)
 If you remove the ContextHolder and make sure the eventlistener is
 initialized only once it should be fine. Core should just create a
 single instance of the Search listener for all events, this is already
 the case afaik.

 Sanne

 2010/2/1 Steve Ebersole :
> 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 
>>>  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 ->
 Se

Re: [hibernate-dev] EMF / EM properties

[Steve Ebersole]

Here is the basic idea: http://pastebin.com/m6add9d4b

Rather than passing around Properties, we'd pass somethign like that
around.  Then we'd use its "getConsumedProperties".


On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
> That's the point Hardy, the list of consumed properties is not known in 
> advance in Hibernate search. Or is the plan get core pass all the raw 
> Properties and HSearch return the list of properties it really wants? In 
> which case it will return all of them to implement our current approach.
> 
> I guess the point is that I am lost and don't see how (my understanding of) 
> the pull second option can work for Search.
> 
> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:
> 
> > 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  
> > 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
> >> st...@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 
> >  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)?

Re: [hibernate-dev] EMF / EM properties

[Sanne Grinovero]

Hi Steve,
please expose in some way the fullPropertySet too, as Search needs to
be able to get a list of all defined keys, for example it reads
options like

hibernate .search.Animals.batch.merge_factor = 20
or
hibernate .search.Animals.5.batch.merge_factor = 30

Where Animals is the name of an index, and the 5 stands for an option
to override the fifth index shard.

Also keep in mind I know of some users on the forum who added "own"
properties to configure their custom extensions, so it would be a good
idea to be able to read all kind of properties at runtime.
Additionally the Infinispan team is asking for "dynamic" configuration
capabilities in Search, so it's possible that some option will need to
be read lazily, i.e. not at framework startup but in a later
timeframe, for example when we first see an event about a new -
previously unmapped - entity.

Did you consider "key scoping" of the Properties, something like
Search already does to parse the above structure as a tree?
In short it hides all properties not having a key which begins with a
specified prefix, it is recursive and extends Properties:
http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/backend/configuration/MaskedProperty.java?r=17630

Sanne


2010/2/3 Steve Ebersole :
> Here is the basic idea: http://pastebin.com/m6add9d4b
>
> Rather than passing around Properties, we'd pass somethign like that
> around.  Then we'd use its "getConsumedProperties".
>
>
> On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
>> That's the point Hardy, the list of consumed properties is not known in 
>> advance in Hibernate search. Or is the plan get core pass all the raw 
>> Properties and HSearch return the list of properties it really wants? In 
>> which case it will return all of them to implement our current approach.
>>
>> I guess the point is that I am lost and don't see how (my understanding of) 
>> the pull second option can work for Search.
>>
>> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:
>>
>> > 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  
>> > 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
>> >> st...@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 
>> >  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

Re: [hibernate-dev] EMF / EM properties

[Steve Ebersole]

First, this is not the option I suggest for now.  It's pretty invasive
change

Well exposing the full set of properties sort of defeats the entire
purpose no?


On Wed, 2010-02-03 at 14:42 +0100, Sanne Grinovero wrote:
> Hi Steve,
> please expose in some way the fullPropertySet too, as Search needs to
> be able to get a list of all defined keys, for example it reads
> options like
> 
> hibernate .search.Animals.batch.merge_factor = 20
> or
> hibernate .search.Animals.5.batch.merge_factor = 30
> 
> Where Animals is the name of an index, and the 5 stands for an option
> to override the fifth index shard.
> 
> Also keep in mind I know of some users on the forum who added "own"
> properties to configure their custom extensions, so it would be a good
> idea to be able to read all kind of properties at runtime.
> Additionally the Infinispan team is asking for "dynamic" configuration
> capabilities in Search, so it's possible that some option will need to
> be read lazily, i.e. not at framework startup but in a later
> timeframe, for example when we first see an event about a new -
> previously unmapped - entity.
> 
> Did you consider "key scoping" of the Properties, something like
> Search already does to parse the above structure as a tree?
> In short it hides all properties not having a key which begins with a
> specified prefix, it is recursive and extends Properties:
> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/backend/configuration/MaskedProperty.java?r=17630
> 
> Sanne
> 
> 
> 2010/2/3 Steve Ebersole :
> > Here is the basic idea: http://pastebin.com/m6add9d4b
> >
> > Rather than passing around Properties, we'd pass somethign like that
> > around.  Then we'd use its "getConsumedProperties".
> >
> >
> > On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
> >> That's the point Hardy, the list of consumed properties is not known in 
> >> advance in Hibernate search. Or is the plan get core pass all the raw 
> >> Properties and HSearch return the list of properties it really wants? In 
> >> which case it will return all of them to implement our current approach.
> >>
> >> I guess the point is that I am lost and don't see how (my understanding 
> >> of) the pull second option can work for Search.
> >>
> >> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:
> >>
> >> > 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  
> >> > 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
> >> >> st...@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.
> >> >>
>

Re: [hibernate-dev] EMF / EM properties

[Sanne Grinovero]

sorry I didn't understand what the purpose is, I just wanted to warn
that Search needs to read all keys, and doesn't know the exact names
beforehand.
Consolidating the constants in a single place looks like a good thing,
just wanted to check you aren't going to hide the other properties for
now. I missed the reason of why the discussion switched from
consolidating constants to changing the properties management.

cheers,
Sanne

2010/2/3 Steve Ebersole :
> First, this is not the option I suggest for now.  It's pretty invasive
> change
>
> Well exposing the full set of properties sort of defeats the entire
> purpose no?
>
>
> On Wed, 2010-02-03 at 14:42 +0100, Sanne Grinovero wrote:
>> Hi Steve,
>> please expose in some way the fullPropertySet too, as Search needs to
>> be able to get a list of all defined keys, for example it reads
>> options like
>>
>> hibernate .search.Animals.batch.merge_factor = 20
>> or
>> hibernate .search.Animals.5.batch.merge_factor = 30
>>
>> Where Animals is the name of an index, and the 5 stands for an option
>> to override the fifth index shard.
>>
>> Also keep in mind I know of some users on the forum who added "own"
>> properties to configure their custom extensions, so it would be a good
>> idea to be able to read all kind of properties at runtime.
>> Additionally the Infinispan team is asking for "dynamic" configuration
>> capabilities in Search, so it's possible that some option will need to
>> be read lazily, i.e. not at framework startup but in a later
>> timeframe, for example when we first see an event about a new -
>> previously unmapped - entity.
>>
>> Did you consider "key scoping" of the Properties, something like
>> Search already does to parse the above structure as a tree?
>> In short it hides all properties not having a key which begins with a
>> specified prefix, it is recursive and extends Properties:
>> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/backend/configuration/MaskedProperty.java?r=17630
>>
>> Sanne
>>
>>
>> 2010/2/3 Steve Ebersole :
>> > Here is the basic idea: http://pastebin.com/m6add9d4b
>> >
>> > Rather than passing around Properties, we'd pass somethign like that
>> > around.  Then we'd use its "getConsumedProperties".
>> >
>> >
>> > On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
>> >> That's the point Hardy, the list of consumed properties is not known in 
>> >> advance in Hibernate search. Or is the plan get core pass all the raw 
>> >> Properties and HSearch return the list of properties it really wants? In 
>> >> which case it will return all of them to implement our current approach.
>> >>
>> >> I guess the point is that I am lost and don't see how (my understanding 
>> >> of) the pull second option can work for Search.
>> >>
>> >> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:
>> >>
>> >> > 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 
>> >> >  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
>> >> >> st...@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] 
>> >> >>

[hibernate-dev] Unable to dispatch Entities in different jars

[Bouiaw]

Hi,

I would like to warn you about a blocking (from my point of view)
issue in Hibernate 3.5 (JIRA issue :
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4864).

Dispatching entities is not supported out of the box by Hibernate/JPA,
but with a small tweak commonly used
(http://ancientprogramming.blogspot.com/2007/05/multiple-persistencexml-files-and.html)
it is possible to acheive this.

This worked with previous version of Hibernate, but not anymore in
Hibernate 3.5 betas.

Even if this is not specified in JPA, this is mandatory for a lot of
developer to do modular applications (each module (JAR) provide its
own DAO, business and model layer).

I hope you will be able to fix HHH-4864, because this is a blocking
point for a lot of developers.

Thanks in advance for your feedback,
Bouiaw
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EMF / EM properties

[Steve Ebersole]

I specifically said I did not want to "consolidate the constants in a
single place".  Not in terms of this anyway.  Because we will not know
them all ahead of time.  Again, I don't see the difference between what
you mention and what would be needed for caching.

Emmanuel was asking specifically about the specific "second pull
approach", which is the context of my answer.  There, given the way
y'all decided to form these property names, the only real option is to
process all properties starting with "hibernate.search" since that's the
most common base.  

For caching (and search would fit here), I'd expect something like:

interface PropertyConsumer {
public boolean consumes(String name);
public void consume(String name, Object value);
}

class ConfigPropertySet {
...

void consumeProperties(PropertyConsumer consumer) {
Iterator itr = fullPropertySet.entries().iterator();
while ( itr.hasNext() ) {
Map.Entry entry = (Map.Entry) itr.next();
final String name = entry.getKey();
if ( consumer.consumes( name ) ) {
register( name, entry.getValue() ):
consumer.consume( name, entry.getValue() );
}
}
}
}

Or maybe even just:

interface PropertyConsumer {
public boolean consume(String name, Object value);
}

class ConfigPropertySet {
...

void consumeProperties(PropertyConsumer consumer) {
Iterator itr = fullPropertySet.entries().iterator();
while ( itr.hasNext() ) {
Map.Entry entry = (Map.Entry) itr.next();
final String name = entry.getKey();
if ( consumer.consume( name, entry.getValue() ) ) {
register( name, entry.getValue() ):
}
}
}
}


On Wed, 2010-02-03 at 17:19 +0100, Sanne Grinovero wrote:
> sorry I didn't understand what the purpose is, I just wanted to warn
> that Search needs to read all keys, and doesn't know the exact names
> beforehand.
> Consolidating the constants in a single place looks like a good thing,
> just wanted to check you aren't going to hide the other properties for
> now. I missed the reason of why the discussion switched from
> consolidating constants to changing the properties management.
> 
> cheers,
> Sanne
> 
> 2010/2/3 Steve Ebersole :
> > First, this is not the option I suggest for now.  It's pretty invasive
> > change
> >
> > Well exposing the full set of properties sort of defeats the entire
> > purpose no?
> >
> >
> > On Wed, 2010-02-03 at 14:42 +0100, Sanne Grinovero wrote:
> >> Hi Steve,
> >> please expose in some way the fullPropertySet too, as Search needs to
> >> be able to get a list of all defined keys, for example it reads
> >> options like
> >>
> >> hibernate .search.Animals.batch.merge_factor = 20
> >> or
> >> hibernate .search.Animals.5.batch.merge_factor = 30
> >>
> >> Where Animals is the name of an index, and the 5 stands for an option
> >> to override the fifth index shard.
> >>
> >> Also keep in mind I know of some users on the forum who added "own"
> >> properties to configure their custom extensions, so it would be a good
> >> idea to be able to read all kind of properties at runtime.
> >> Additionally the Infinispan team is asking for "dynamic" configuration
> >> capabilities in Search, so it's possible that some option will need to
> >> be read lazily, i.e. not at framework startup but in a later
> >> timeframe, for example when we first see an event about a new -
> >> previously unmapped - entity.
> >>
> >> Did you consider "key scoping" of the Properties, something like
> >> Search already does to parse the above structure as a tree?
> >> In short it hides all properties not having a key which begins with a
> >> specified prefix, it is recursive and extends Properties:
> >> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/backend/configuration/MaskedProperty.java?r=17630
> >>
> >> Sanne
> >>
> >>
> >> 2010/2/3 Steve Ebersole :
> >> > Here is the basic idea: http://pastebin.com/m6add9d4b
> >> >
> >> > Rather than passing around Properties, we'd pass somethign like that
> >> > around.  Then we'd use its "getConsumedProperties".
> >> >
> >> >
> >> > On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote:
> >> >> That's the point Hardy, the list of consumed properties is not known in 
> >> >> advance in Hibernate search. Or is the plan get core pass all the raw 
> >> >> Properties and HSearch return the list of properties it really wants? 
> >> >> In which case it will return all of them to implement our current 
> >> >> approach.
> >> >>
> >> >> I guess the point is that I am lost and don't see how (my understanding 
> >> >> of) the pull second option can work for Search.
> >> >>
> >> >> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote:
> >> >>
> >> >> > For the Hibernate Search case I could imagine to implement Steve's 
> >> >> > second pull
> >> >> > approach. Search already defines an inte

Re: [hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

I believe Steve is on the right track. As he is saying  
http://pastebin.com/m6add9d4b
describes the "second pull" approach which he have been talking about in  
one of the earlier
mails. This is very similar to what I had in mind as well, except I  
thought about sub-classing
java.util.Properties.

--Hardy


On Wed, 03 Feb 2010 14:26:59 -0300, Steve Ebersole   
wrote:

> I specifically said I did not want to "consolidate the constants in a
> single place".  Not in terms of this anyway.  Because we will not know
> them all ahead of time.  Again, I don't see the difference between what
> you mention and what would be needed for caching.
>
> Emmanuel was asking specifically about the specific "second pull
> approach", which is the context of my answer.  There, given the way
> y'all decided to form these property names, the only real option is to
> process all properties starting with "hibernate.search" since that's the
> most common base.
>
> For caching (and search would fit here), I'd expect something like:
>
> interface PropertyConsumer {
> public boolean consumes(String name);
> public void consume(String name, Object value);
> }
>
> class ConfigPropertySet {
> ...
>
> void consumeProperties(PropertyConsumer consumer) {
> Iterator itr = fullPropertySet.entries().iterator();
> while ( itr.hasNext() ) {
> Map.Entry entry = (Map.Entry) itr.next();
> final String name = entry.getKey();
> if ( consumer.consumes( name ) ) {
> register( name, entry.getValue() ):
> consumer.consume( name, entry.getValue() );
> }
> }
> }
> }
>
> Or maybe even just:
>
> interface PropertyConsumer {
> public boolean consume(String name, Object value);
> }
>
> class ConfigPropertySet {
> ...
>
> void consumeProperties(PropertyConsumer consumer) {
> Iterator itr = fullPropertySet.entries().iterator();
> while ( itr.hasNext() ) {
> Map.Entry entry = (Map.Entry) itr.next();
> final String name = entry.getKey();
> if ( consumer.consume( name, entry.getValue() ) ) {
> register( name, entry.getValue() ):
> }
> }
> }
> }

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EMF / EM properties

[Steve Ebersole]

Word of warning.  I actually tried that :)

It ended up being all the properties.  Something was pulling them all.
I tried a sublass+delegate approach (I also had trouble getting the
"default properties" to work with just straight subclassing).

FYI...


On Wed, 2010-02-03 at 15:50 -0300, Hardy Ferentschik wrote:
> I believe Steve is on the right track. As he is saying  
> http://pastebin.com/m6add9d4b
> describes the "second pull" approach which he have been talking about in  
> one of the earlier
> mails. This is very similar to what I had in mind as well, except I  
> thought about sub-classing
> java.util.Properties.
> 
> --Hardy
> 
> 
> On Wed, 03 Feb 2010 14:26:59 -0300, Steve Ebersole   
> wrote:
> 
> > I specifically said I did not want to "consolidate the constants in a
> > single place".  Not in terms of this anyway.  Because we will not know
> > them all ahead of time.  Again, I don't see the difference between what
> > you mention and what would be needed for caching.
> >
> > Emmanuel was asking specifically about the specific "second pull
> > approach", which is the context of my answer.  There, given the way
> > y'all decided to form these property names, the only real option is to
> > process all properties starting with "hibernate.search" since that's the
> > most common base.
> >
> > For caching (and search would fit here), I'd expect something like:
> >
> > interface PropertyConsumer {
> > public boolean consumes(String name);
> > public void consume(String name, Object value);
> > }
> >
> > class ConfigPropertySet {
> > ...
> >
> > void consumeProperties(PropertyConsumer consumer) {
> > Iterator itr = fullPropertySet.entries().iterator();
> > while ( itr.hasNext() ) {
> > Map.Entry entry = (Map.Entry) itr.next();
> > final String name = entry.getKey();
> > if ( consumer.consumes( name ) ) {
> > register( name, entry.getValue() ):
> > consumer.consume( name, entry.getValue() );
> > }
> > }
> > }
> > }
> >
> > Or maybe even just:
> >
> > interface PropertyConsumer {
> > public boolean consume(String name, Object value);
> > }
> >
> > class ConfigPropertySet {
> > ...
> >
> > void consumeProperties(PropertyConsumer consumer) {
> > Iterator itr = fullPropertySet.entries().iterator();
> > while ( itr.hasNext() ) {
> > Map.Entry entry = (Map.Entry) itr.next();
> > final String name = entry.getKey();
> > if ( consumer.consume( name, entry.getValue() ) ) {
> > register( name, entry.getValue() ):
> > }
> > }
> > }
> > }
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-- 
Steve Ebersole 
Hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

Ahh, I was wondering why you did not suggest sub-classing in your approach.
Funny that you say that all properties got pulled then. Any ideas what the  
issue was?

--Hardy


On Wed, 03 Feb 2010 15:56:02 -0300, Steve Ebersole   
wrote:

> Word of warning.  I actually tried that :)
>
> It ended up being all the properties.  Something was pulling them all.
> I tried a sublass+delegate approach (I also had trouble getting the
> "default properties" to work with just straight subclassing).
>
> FYI...


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EMF / EM properties

[Steve Ebersole]

Nope.  I gave up after that.  I had the far more pressing jpa feature of
"load an entity by another entity's id" to implement :D

If you can work that out, that would be an alternative as well.
Obviously not invasive at all.

On Wed, 2010-02-03 at 16:02 -0300, Hardy Ferentschik wrote:
> Ahh, I was wondering why you did not suggest sub-classing in your approach.
> Funny that you say that all properties got pulled then. Any ideas what the  
> issue was?
> 
> --Hardy
> 
> 
> On Wed, 03 Feb 2010 15:56:02 -0300, Steve Ebersole   
> wrote:
> 
> > Word of warning.  I actually tried that :)
> >
> > It ended up being all the properties.  Something was pulling them all.
> > I tried a sublass+delegate approach (I also had trouble getting the
> > "default properties" to work with just straight subclassing).
> >
> > FYI...
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-- 
Steve Ebersole 
Hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

On Wed, 03 Feb 2010 16:10:39 -0300, Steve Ebersole   
wrote:

> Nope.  I gave up after that.  I had the far more pressing jpa feature of
> "load an entity by another entity's id" to implement :D

Yeah I know what you mean, implementing the right property access type for  
the
meta model generator in case of mixed configuration (annotations + xml) is  
a real
pita.

> If you can work that out, that would be an alternative as well.
> Obviously not invasive at all.

It would be the nicer way of doing it since non-invasive. A shame that  
there is
so often a rub with the simple ideas :(

--Hardy


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev