[hibernate-dev] R: [HSearch] Configuration properties

[Sanne Grinovero]

2010/7/12 Hardy Ferentschik <hibernate at ferentschik.de>:
> Hi Sanne,
>
> I guess you are referring to HSEARCH-517 and the WeakHashMap in
> ContextHolder.
> 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
> configuration
> properties in SearchFactory.

+1
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.

Sanne

>
>
> --Hardy
>
> On Fri, 09 Jul 2010 19:49:29 +0200, Sanne Grinovero
> <sanne.grinovero at gmail.com> wrote:
>
>> 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
>> weakhashmap)
>>
>> cheers,
>> Sanne
>>
>> Il giorno 09/lug/2010 18:47, "Hardy Ferentschik"
>> <hibernate at ferentschik.de>
>> ha scritto:
>>
>> Hi,
>>
>> 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
>> "hibernate.search.jmx_enabled.
>>
>> 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?
>>
>> --Hardy
>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>