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 <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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
