[hibernate-dev] Batch indexing API

2009-06-30 Thread Sanne Grinovero
Hello, I need some comments about the batch indexing API, so that I can stabilize it and write the documentation; I might even blog about it :-) Here is the current sketch: http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/Indexer.java?r=16967 Emmanuel I re

[hibernate-dev] JBoss Cache / Infinispan index copying in HSearch

2009-06-30 Thread Łukasz Moreń
Hi, I'm reviving previous discussion. #3 Index copy > this is what you are describing, copying the index using JGroups instead of > my file system approach. This might have merits esp as we could diminish > network traffic using multicast but it also require to rethink the master / > slave modus

Re: [hibernate-dev] "plugin loading" in Hibernate Search

2009-06-30 Thread Sanne Grinovero
cool, fast answers! opened HSEARCH-384 I'll see what I can do about the context-dependent error messages, I'm experimenting with a String parameter to add some "component description", but I have yet to verify if it's enough for all cases. 2009/6/30 Emmanuel Bernard : > Yes go ahead. The hard par

Re: [hibernate-dev] "plugin loading" in Hibernate Search

2009-06-30 Thread Emmanuel Bernard
Yes go ahead. The hard part is to provide a meaningful error report which depends on the context. On Tue, 2009-06-30 at 14:50 +0200, Sanne Grinovero wrote: > Hi, > the code of Hibernate Search is very extensible, as nearly all > internal modules are "overridable" by user provided implementation; >

Re: [hibernate-dev] "plugin loading" in Hibernate Search

2009-06-30 Thread Hardy Ferentschik
On Tue, 30 Jun 2009 14:50:54 +0200, Sanne Grinovero wrote: I am building a util class to get some consistency, and plan to unit test this extensively to make sure it throws understandable exceptions for the most common mistakes (hey, I need a public no-args constructor! / not implementing th

[hibernate-dev] "plugin loading" in Hibernate Search

2009-06-30 Thread Sanne Grinovero
Hi, the code of Hibernate Search is very extensible, as nearly all internal modules are "overridable" by user provided implementation; this external classes are loaded by defining a short name (in case of built-in extensions) or fully qualified names to load whatever is on the classpath to replace