On 9 mars 2010, at 14:37, Sanne Grinovero wrote: > Inline: > > 2010/3/9 Emmanuel Bernard <emman...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
