[hibernate-dev] [HSearch] Getting rid of ContextHolder (WAS:Configuration properties)

[Hardy Ferentschik]

Great. Deprecating the default constructor in FullTextIndexEventListener  
and the
properties discussion are indeed orthogonal. I start with committing the  
upgrade to
Core 3.6 together with the FullTextIndexEventListener changes.

We can take the properties discussion separate.

--Hardy


On Wed, 14 Jul 2010 15:54:33 +0200, Emmanuel Bernard  
<emmanuel at hibernate.org> wrote:

> Sorry for the delay,
> Good idea, with a useful exception if possible on the deprecated  
> constructor.
>
> Exposing properties is a different matter altogether, I'd rather  
> separate these discussions.
>
> On 12 juil. 2010, at 10:49, Hardy Ferentschik wrote:
>
>> 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.
>>
>>
>> --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
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>