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 <emman...@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.grinov...@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" >>> <hibern...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
