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 <hibern...@ferentschik.de>:
> On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero
> <sanne.grinov...@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
