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
Met vriendelijke groet,
Peter Schuler
Ordina ICT J-technologies
tel: +31 (0)30 6637788
mob: +31 (0)6 55788758
e-mail: peter.schu...@ordina.nl
Disclaimer
Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor
de geadresseerde. Indien u niet de
bedoe
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 whate
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
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. Wh
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 DirectoryProvide
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
