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
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
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
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
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
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
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
