Lib Directories

Here we describe two simple and effective methods to make the .jar files for Solr plugins visible to Solr.

Such files are sometimes called "libraries" or "libs" for short. Essentially you can put them in some special places or explicitly tell Solr about them from your config.

If there is overlap or inter-dependencies between libraries, then pay attention to the order. You can think of it like a stack that is searched top-down. At the top are the lib directives in reverse order, then Solr core’s lib, then Solr home’s lib, then Solr itself.

Lib Directories

There are several special places you can place Solr plugin .jar files, described in the table below:

Location Visible To Purpose Additional Notes

<solr_install>/lib/

Everything (Node-level plugins, Core-level plugins, bin/solr tools)

Any plugins that administrators want to make available to all of Solrand its tooling, esp. when building a custom Solr package or Dockerfile.

N/A

<solr_home/lib/

Node-level plugins, Core-level plugins

Useful when plugins should be made available to all of Solr, but cannot be put in <solr_install>/lib/ for whatever reason (e.g. Solr installed on read-only file system)

Directory not present by default and must be created by administrators. See Taking Solr to Production.

<core_instance>/lib/

Core-level plugins (for a specific core)

User-managed clusters or single-node installations that want to make a plugin visible to a specific Solr core, but not others.

Directory is not created by default, and must be created by administrators adjacent to <core_instance>/conf/

<solr_install>/server/solr-webapp/webapp/WEB-INF/lib/

Everything (Node-level plugins, Core-level plugins, bin/solr tools)

Intended for Solr’s own jars and dependencies

Should not be used for plugins, except in the case of a few rare plugin typs whose documentation explicitly calls out the need for placement here.

<solr_install>/server/lib/ext

Everything (Node-level plugins, Core-level plugins, bin/solr tools)

Intended to contain Jetty jars and other things needed by the Jetty servlet classpath. Not typically used for plugins

N/A

Note that while it’s possible to place custom code in <solr_install>/server/solr-webapp/webapp/WEB-INF/lib/ and <solr_install>/server/lib/ext/, doing so is discouraged as these directories are intended for holding Solr and Jetty code, respectively.

Lib Directives in SolrConfig

<lib/> directives are deprecated and will be removed in Solr 10.0. In the interim, Solr disables this feature by default in order to minimize the security exposure of our users. Expert users who wish to enable <lib/> directives in their deployment may do so by specifying setting the solr.config.lib.enabled sysprop to true.

Both plugin and resource file paths are configurable via <lib/> directives in solrconfig.xml. When a directive matches a directory, then resources can be resolved from it. When a directive matches a .jar file, Solr plugins and their dependencies are resolved from it. Resources can be placed in a .jar too but that’s unusual. It’s erroneous to refer to any other type of file.

A <lib/> directive must have one (not both) of these two attributes:

  • path: used to refer to a single directory (for resources) or file (for a plugin .jar)

  • dir: used to refer to all direct descendants of the specified directory. Optionally supply a regex attribute to filter these to those matching the regular expression.

All directories are resolved as relative to the Solr core’s instanceDir.

These examples show how to load modules into Solr:

  <lib dir="${solr.install.dir:../../../..}/modules/extraction/lib" regex=".*\.jar" />

  <lib dir="${solr.install.dir:../../../..}/modules/clustering/lib/" regex=".*\.jar" />

  <lib dir="${solr.install.dir:../../../..}/modules/langid/lib/" regex=".*\.jar" />

  <lib dir="${solr.install.dir:../../../..}/modules/ltr/lib/" regex=".*\.jar" />