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. >> >> 1B) JGroups >> Infinispan depends on newer JGroups version than the one currently >> tested by the jgroups backend. I'd expect the new version to work the >> same, but are we going to explicitly depend on the same version of >> Infinispan? > > +1, we probably need to use what Hibernate Core is using, ie a central place > to declare deps for all HSearch "modules" > >> >> 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". _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
