2010/7/12 Hardy Ferentschik <hibernate(a)ferentschik.de>:
I guess you are referring to HSEARCH-517 and the WeakHashMap in
Reading through the comments I am wondering whether we couldn't deprecate
the default constructor in FullTextIndexEventListener now? The
annotation module in Core has now been merged with the core module so
ContextHolder seems obsolete.
I am all up for it especially if this opens the door to exposing the
properties in SearchFactory.
I've also had many needs for the configuration in the past, it's
always been hard to workaround this limitation, and harder yet to make
sure we wouldn't leak memory (and I'm still not convinced about that).
Also then we could remove
org.hibernate.search.util.WeakIdentityHashMap, a hard to understand
and to maintain class.
On Fri, 09 Jul 2010 19:49:29 +0200, Sanne Grinovero
> Hi Hardy! because it's the key for the static weakhashmap for the
> autoregistration of listeners, that would introduce a memory leak.
> I had proposed to care for registration of listeners in other ways, don't
> have the reference now from the phone (I'd +1 to remove the static
> Il giorno 09/lug/2010 18:47, "Hardy Ferentschik"
> ha scritto:
> just wondering whether there is a reason why we don't expose the
> configuration properties in SearchFactory?
> I think we talked about this once, but I cannot remember exactly.
> I noticed that the properties are now exposed in
> StateSearchFactoryImplementor anyways. Maybe
> we could push this all the way down to SearchFactory?
> I need would need access to the properties and several places to for
> example check for hibernate.search.generate_statistics or
> While looking at the code I also started to wonder whether we need all
> these sub-interfaces for SearchFactory. Currently we have
> SearchFactory -> SearchFactoryIntegrator -> SearchFactoryImplementor ->
> StateSearchFactoryImplementor -> Mutable-/Immutable-SearchFactory
> Is this really all needed?
> hibernate-dev mailing list