lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Classloader for plugin jar
Date Mon, 01 Sep 2014 15:55:41 GMT
On 9/1/2014 9:30 AM, Nimrod Cohen wrote:
> We have a plugin that works as long as we have all the jars in sold
> webapps\web-inf\lib
> Once we copy the jar to a different location we solr starts ok but on
> run time we get the below error, we think that solr don’t use the right
> class loader.

My reply got long-winded, sorry about that.

The solution that I have found which works the best is to put all
contrib and third-party jars for Solr components into one place --
${solr.solr.home}/lib.  If you use this approach, they only get loaded
once.  If you've got many cores using the <lib> tag in solrconfig.xml,
then the jars will be loaded once for every single core.  Even if this
doesn't use extra memory (I don't know if it does), it will slow down
core loading.

The solr.solr.home system property is the location of the solr.xml file
that configures Solr's core loader.  If you don't set it, it defaults to
"./solr" -- relative to the current working directory of the process
that runs Solr.

This approach *usually* works, but not always.  There is one case that I
know of where it won't work -- the JTS jar required by advanced spatial
features must be part of the libraries extracted from the solr WAR, or
its classes cannot be used.  I don't know if your plugin suffers from
the same problem, but I would suspect that it does not.

If you're using 4.2.1 or earlier, you must tell Solr to use the lib
directory I've described with the following attribute on the solr tag in


If you're on version 4.3 or later, specifying the configuration above
can actually cause it not to work, even if you're using the old solr.xml
format.  Solr will automatically use that location without any
configuration at all.  There's an issue in Jira about this problem:


View raw message