[hibernate-dev] [HSearch] Configuration properties

Hardy Ferentschik hibernate at ferentschik.de
Mon Jul 12 10:43:09 EDT 2010


On Mon, 12 Jul 2010 15:31:17 +0200, Emmanuel Bernard  
<emmanuel at hibernate.org> wrote:

>> 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.

Personally I don't see a problem of having access to the properties. Not  
having
access on the other hand can make code more complicated than it has to be.

Let's take MassIndexerImpl for example. This class instantiates a  
SimpleIndexingProgressMonitor
at the moment. It also gets passed the SearchFactoryImplementor. If the  
SearchFactoryImplementor
would give me access to the properties I could just check  
hibernate.search.jmx_enabled and
act decide whether I want to create a JMXIndexingProgressMonitor. Or maybe  
we want to
make the progress montior configurable via  
hibernate.search.progress_monitor_class.
Would you prefer to keep adding methods to SearchFactoryImplementor?


>> 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

Is this not encouraging things like:

if ( searchFactory instanceof StateSearchFactoryImplementor ) {
	StateSearchFactoryImplementor stateSearchFactoryImplementor = (  
StateSearchFactoryImplementor ) searchFactory;
	...
}


>> 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.

Ok, merging SearchFactoryIntegrator into SearchFactoryInplementor seems to  
be a step forward.
When you say "work in progress" - what is the status on the methods  
defined in
SearchFactoryIntegrator?

--Hard




More information about the hibernate-dev mailing list