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&gt; 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

2010/7/12 Hardy Ferentschik <hibernate(a)ferentschik.de&gt;: > 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.

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&gt; 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&gt; >> 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