[hibernate-dev] [HSearch] Upgrade to Lucene 3.0

[Emmanuel Bernard]

Can't do that easily. The VM won't load your annotation so you will have to read the .class file.

On 9 sept. 2010, at 15:00, Sanne Grinovero wrote:

> What I mean is that when you read the annotation having
> @TokenizerDef(factory = org.apache.solr.analysis.StandardTokenizerFactory.class)
> 
> you could try starting it, but if it doesn't work you do
> factory.getName().replace("org.apache.solr",
> "org.hibernate.search.analysis")
> and then use the new one loaded by reflection, after spitting out a
> fat warning about the fact that you're messing with it, and that the
> user will get a different class than what he asked for.
> If the "translated name" points to a non-existent class, something
> else is wrong.
> 
> Sanne
> 
> 2010/9/9 Hardy Ferentschik <hibernate at ferentschik.de>:
>> On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero
>> <sanne.grinovero at gmail.com> wrote:
>> 
>>> So if the Solr packages are renamed, I'd do it once and for all,
>>> pointing to delegators we could fix in case of need, or as we do
>>> control the class loading ourself, we could "translate" the requested
>>> package name to the new one? So you might actually rename the packages
>>> AND keep backwards compatibility - not sure if that's doable, but sure
>>> it might seem weird to receive a different class than the one asked
>>> for, the reflection loader should apply this trick only if it's able
>>> to detect that it would load an incompatible package, so that in
>>> future people can drop in a fixed up to date Solr and get the classes
>>> they asked for.
>> 
>> Not sure if I follow you here. Let's take an example:
>> 
>> 
>> 
>> import org.apache.solr.analysis.GermanStemFilterFactory;
>> import org.apache.solr.analysis.LowerCaseFilterFactory;
>> import org.apache.solr.analysis.SnowballPorterFilterFactory;
>> import org.apache.solr.analysis.StandardTokenizerFactory;
>> ... // non Solr imports
>> 
>> @Entity
>> @Indexed
>> @AnalyzerDefs({
>>                @AnalyzerDef(name = "de",
>>                                tokenizer = @TokenizerDef(factory =
>> StandardTokenizerFactory.class),
>>                                filters = {
>>                                                @TokenFilterDef(factory =
>> LowerCaseFilterFactory.class),
>>                                                @TokenFilterDef(factory =
>> GermanStemFilterFactory.class)
>>                                })
>> })
>> 
>> After renaming the packages the example would look something like this:
>> 
>> 
>> import org.hibernate.search.analysis.GermanStemFilterFactory;
>> import org.hibernate.search.analysis.LowerCaseFilterFactory;
>> import org.hibernate.search.analysis.SnowballPorterFilterFactory;
>> import org.hibernate.search.analysis.StandardTokenizerFactory;
>> ... // non Solr imports
>> 
>> @Entity
>> @Indexed
>> @AnalyzerDefs({
>>                @AnalyzerDef(name = "de",
>>                                tokenizer = @TokenizerDef(factory =
>> StandardTokenizerFactory.class),
>>                                filters = {
>>                                                @TokenFilterDef(factory =
>> LowerCaseFilterFactory.class),
>>                                                @TokenFilterDef(factory =
>> GermanStemFilterFactory.class)
>>                                })
>> })
>> 
>> 
>> How would I be able to keep backwards compatibiltiy? The Solr classes are
>> not loaded dynamically by us, but
>> explicitly referenced in the import statements.
>> 
>> 
>>> Final provoking thought, why is it so important to switch to Lucene 3?
>>> couldn't we support both, and have people try to understand that if
>>> they want backwards compatibility they should use Lucene 2.9 and if
>>> they want Lucene 3 they won't be able to use Solr analyzers, pointing
>>> to the fact that a compatible Solr wasn't released yet?
>> 
>> You mean we should behave differently depending on which version of Lucene
>> gets added to the classpath?
>> How do we set this up? Could we have multiple search artifacts using maven's
>> qualified mechanism? (just
>> speculating here)
>> Or are you talking about multiple development branches?
>> 
>> 
>> --Hardy
>> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev