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(a)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(a)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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev