You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jan Nehring <ja...@semperlink.com> on 2014/05/27 10:13:58 UTC

Classpath for Solr Plugins

Hi!

We have developed a custom tokenizer for Solr 4.3. Our Solr Server is started as a war file inside of a java application using jetty. When the custom tokenizer is in the class path oft the enclosing java application Solr fails on startup. The error is ClassCastException ArabicLetterTokenizer which is a class we don't use in our system. We can put the custom tokenizer in the Solr classpath from any other location but it needs to reside in the classpath of  the enclosing application due to the overall architecture of our system.

The solution to our problem was to manipulate Jettys class loading behaviour:

Server server = new org.eclipse.jetty.server.Server();
WebAppContext webapp = new WebAppContext();
webapp.setParentLoaderPriority(true); 		// <-- this line
server.setHandler(webapp);
...

Using setParentLoaderPriority( true ) solved all our classpath problems. We didnt even have to use any oft the various methods to load the custom tokenizer in the Solr class path. My questions:

1) This method works too good and is too simple to implement, where is the drawback?
2) If there is no drawback why is it not mentioned in the Solr Doc in https://wiki.apache.org/solr/SolrPlugins ? 

Thank you very much Jan



Re: Classpath for Solr Plugins

Posted by Alexandre Rafalovitch <ar...@gmail.com>.
In terms of drawback, I think strong dependence on Jetty is probably
one. Custom Java code is another. Most of the people run Solr as a
black box.

For the proposed solution, as the document said, usually the plugins
are placed in the directory defined in solrconfig.xml. So, most of the
people do not need other methods.

I am glad you have the solutions that worked for you, but it's a
little hard to tell whether the original problem is applicable to
anybody else.

Perhaps, your email to the mailing list can be the documentation
required for those who have similar issues. If it becomes something
bigger, a documentation JIRA can be created (by anybody).

Regards,
  Alex.


Personal website: http://www.outerthoughts.com/
Current project: http://www.solr-start.com/ - Accelerating your Solr proficiency


On Tue, May 27, 2014 at 3:13 PM, Jan Nehring <ja...@semperlink.com> wrote:
> Hi!
>
> We have developed a custom tokenizer for Solr 4.3. Our Solr Server is started as a war file inside of a java application using jetty. When the custom tokenizer is in the class path oft the enclosing java application Solr fails on startup. The error is ClassCastException ArabicLetterTokenizer which is a class we don't use in our system. We can put the custom tokenizer in the Solr classpath from any other location but it needs to reside in the classpath of  the enclosing application due to the overall architecture of our system.
>
> The solution to our problem was to manipulate Jettys class loading behaviour:
>
> Server server = new org.eclipse.jetty.server.Server();
> WebAppContext webapp = new WebAppContext();
> webapp.setParentLoaderPriority(true);           // <-- this line
> server.setHandler(webapp);
> ...
>
> Using setParentLoaderPriority( true ) solved all our classpath problems. We didnt even have to use any oft the various methods to load the custom tokenizer in the Solr class path. My questions:
>
> 1) This method works too good and is too simple to implement, where is the drawback?
> 2) If there is no drawback why is it not mentioned in the Solr Doc in https://wiki.apache.org/solr/SolrPlugins ?
>
> Thank you very much Jan
>
>