On 9 juil. 2010, at 17:46, Hardy Ferentschik wrote: There are several reasons but one of them is to know how things are used and how instead in a more type-safe way. The reason it's in StateSearchFactoryImplementor is for people *not* to access it unless they are in need to clone a SearchFactory Couldn't you have a type-safe object StatisticsConfiguration object containing the already parsed data? SearchFactory is for app developers SearchFactoryIntegrator is for frameworks like Infinispan (but is still a work in progress, we might end up merging it back with SearchFactoryInplementor) SearchFactoryInplementor is for components of HSearch to access metadata These are implementations and not exposed.

On 12 juil. 2010, at 15:43, Hardy Ferentschik wrote: Today in the code, here is the de facto rule (I think this is consistent ATM): - stuffs created at SF init time can access the properties - otherwise, the required state is exposed via the SearchFactoryImplementor That way: - know how things are used and how instead in a more type-safe way - you avoid the redundant property look up (which synchronizes) and parsing If we start mixing stuffs the code will become less readable. Now about the JMXIndexingProgressMonitor: - is there one published for all mass indexers run in parallel? - or is there one per mass indexer - if the latter how will you get the list? Maybe a SFImplementor#getIndexingProgressMonitor(...) or SFImplementor#getIndexingProgressMonitorFactory(...) would be a better contract? Typically people that do (SearchFactoryImpl) sfi today are on for a big surprise for the next release :) Note that I've put it in the spi.internals package to make sure people know they are shooting themselves in the foot. Well I realized that there are really 2 contracts: - one between SearchFactory and frameworks it integrates like Hibernate Core and Infinispan - one between SearchFactory and the internals of Hibernate Search The goal was to not have much problem changing the latter but be more cautious about breaking the former. That being said, I could not make SearchFactoryInplementor disappear from some other SPIs esp for people implementing back ends. My main goal is to limit contract breaks between HSearch and Infinispan at this stage and a dedicated interface looked like a good way to do it.