[hibernate-dev] Hibernate Search: Infinispan DirectoryProvider

[Emmanuel Bernard]

On 9 mars 2010, at 14:37, Sanne Grinovero wrote:

> Inline:
> 
> 2010/3/9 Emmanuel Bernard <emmanuel at hibernate.org>:
>> 
>> On 9 mars 2010, at 12:47, Sanne Grinovero wrote:
>> 
>>> Hi all,
>>> I'd like to merge the Infinispan DirectoryProvider soon:
>>> 
>>> The code is trivial as it was designed primarily for Search, but some
>>> points need to be discussed:
>>> 
>>> 1) Dependencies
>>> 1A) Transaction implementation:
>>> It does require Infinispan modules, most are transitive dependencies of
>>>   <groupId>org.infinispan</groupId>
>>>   <artifactId>infinispan-lucene-directory</artifactId>
>>> 
>>> but it also requires a transaction manager implementation, which is
>>> not enforced by infinispan as any implementation will do.
>>> Shall we "suggest" one as optional dependency?
>>> This is going to add many dependencies, but we need something at least
>>> for tests.
>> 
>> I'd mark it provided or something like that? What is the strategy that the Infiniboys use for their tests?
>> 
> 
> In Infinispan dependencies like jbossjta are in test scope while the
> jboss-transaction-api is in compile scope;
> fine for me, I'm just warning that without modularizing Search this is
> going to introduce many additional jars.

We need to modularize anyway. Waiting for Hardy AFAIR.

>> 
>> 
>>> 
>>> 2) Infinispan initialization
>>> A single CacheManager should be shared across many caches; in practice
>>> while I'd suggest to use a different cache per index we even do
>>> support more than one index in the same cache.
>>> At least a configuration property would be needed to point the
>>> CacheManager initialization to an Infinispan configuration file -
>>> which in turn will lilkely point to a JGroups configuration file.
>>> This configuration property could be global or "directory scoped" like
>>> we do for other properties but that would be complex.
>>> 
>>> I'd suggest a single global CacheManager configuration - which will
>>> trigger a CacheManager initialization in the SearchFactory - and have
>>> different Directories be able to select the cache name and index name
>>> they want to use;
>>> (If two directories use the same cache and same index name they are
>>> sharing the same index)
>>> It would look like:
>>> 
>>> hibernate.search.infinispan_configuration lucene-cluster-conf.xml
>>> hibernate.search.default.directory_provider
>>> org.hibernate.search.store.InfinispanDirectoryProvider
>>> hibernate.search.default.cache_name defaultLuceneIndexes
>>> hibernate.search.Animal.cache_name AnimalsLuceneIndex
>> 
>> Looks good but it means we need some kind of lifecycle hook for this cache manager to be initialized in Hibernate Search before the directory providers.
>> For example it would be nice to pass the properties to this initializer hook and let it decide whether or not it needs to do something on SF init and on SF close. These hooks could be discoverable or example by using the service pattern.
> 
> I'm not sure about which pattern, do you have an example ? google
> found several different things all generically named "service
> pattern".

Sorry I mean the service locator pattern, ie a file named META-INF/org.hibernate.search.Plugin this file containing the plug in to start and use (like BV and JPA do to locate providers.
I'm open to other suggestions.