On 9 juil. 2010, at 17:46, Hardy Ferentschik wrote:
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.
There are several reasons but one of them is to know how things are used and how instead
in a more type-safe way.
I noticed that the properties are now exposed in
StateSearchFactoryImplementor anyways. Maybe
we could push this all the way down to SearchFactory?
The reason it's in StateSearchFactoryImplementor is for people *not* to access it
unless they are in need to clone a 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.
Couldn't you have a type-safe object StatisticsConfiguration object containing the
already parsed data?
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
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
-> Mutable-/Immutable-SearchFactory
These are implementations and not exposed.