I opened https://issues.apache.org/jira/browse/LUCENE-2182 about this problem and already have a fix.
This is really a bug. The solution is simple because you have to load the IMPL class using the same classloader as the passed in interface. The default for Class.forName is the classloader of AttributeSource.class, which is the wrong one. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, December 28, 2009 9:20 AM > To: java-user@lucene.apache.org > Cc: solr-u...@lucene.apache.org > Subject: RE: Using the new tokenizer API from a jar file > > The question on this list was ok,as it shows a minor problem of using the > new TokenStream API with Solr. > > His plugin was loaded correctly, because if Lucene says, that it cannot > find > the *Impl class, it was able to load the interface class before -> the JAR > file is "visible" to the JVM. > > The problem is the following and has to do with classloaders: > > 1. We have different class loaders for different places in Solr. Solr uses > for plugins a SolrResourceLoader that searches for JAR files in the local > lib folder before handling over to the webapp's classloader. > > 2. Initially, the lucene JAR is loaded by the Webapp's class loader > > 3. If a AttributeImpl is placed into a jar file e.g. in the plugin folder > of > solr (the lib folder where solr loads all resources, stop words,...), the > loading mechanism inside AttributeSource.DEFAULT_ATTRIBUTE_FACTORY is > unable > to locate the class file, because Class.forName() always uses the class' > classloader and not the global/thread one's. So AttributeSource will only > find the class file if it is in the *same* directory as the lucene- > core.jar > file (WEB-INF/lib) and so accessible by the webapp's class loader. > > A good introduction about the problem is this one: > http://www.theserverside.com/tt/articles/content/dm_classForname/DynLoad.p > df > > The problem is here described for the JVM extensions folder but also > applies > to solr, because it has another classloader for plugins. > > A solution to fix this would be in lucene to use the thread's context > class > loader in AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, but I strongly > discourage this, as it would break the whole AttributeSource functionality > if you add two different attributes with same class names from different > class loaders to the AttributeSource. > > The only solution to the problem is placing the JAR file inside the > WEB-INF/lib folder where lucene-core.jar is. Plugins in Solr cannot define > own attribute implementations. Alternatively he could try to force preload > the class by calling Class.forName in his plugin initialization code on > the > Impl class. But I am not sure if this works (as Java handles classes from > different classloaders different). > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -----Original Message----- > > From: Chris Hostetter [mailto:hossman_luc...@fucit.org] > > Sent: Monday, December 28, 2009 4:27 AM > > To: java-user@lucene.apache.org > > Subject: Re: Using the new tokenizer API from a jar file > > > > > > : I tried to use it with solr and the problems began. It's always > telling > > me > > : that it cannot find the class GlossAttributeImpl. I think the problem > is > > : that my jar file is added to the class path at run time not from the > > command > > : line. Do you have a good solution or workaround? > > > > You're likely to get mmore helpful answers from other people in the Solr > > User community (solr-u...@lucene.a.o) > > > > As long as you put your jar in the "lib" directory under your solr home > > (or refrence it using a <lib/> directive in your solrconfig.xml) Solr's > > plugin loader will take care of hte classloading for you. > > > > if you are confident you have your jar in the correct place, please > email > > solr-user with the ClassNotFound stack trace from your solr logs, as > well > > as hierarchy of files from your solr home (ie: the output of "find .") > > > > > > -Hoss > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
