Configuring solrconfig.xml

JVM System Properties

Any JVM System properties, usually specified using the -D flag when starting the JVM, can be used as variables in any XML configuration file in Solr.

For example, in the sample solrconfig.xml files, you will see this value which defines the locking type to use:

<lockType>${solr.lock.type:native}</lockType>

Which means the lock type defaults to "native" but when starting Solr, you could override this using a JVM system property by launching the Solr it with:

bin/solr start -Dsolr.lock.type=none

In general, any Java system property that you want to set can be passed through the bin/solr script using the standard -Dproperty=value syntax. Alternatively, you can add common system properties to the SOLR_OPTS environment variable defined in the Solr include file (bin/solr.in.sh or bin/solr.in.cmd). For more information about how the Solr include file works, refer to: Taking Solr to Production.

Config API to Override solrconfig.xml

The Config API allows you to use an API to modify Solr’s configuration, specifically user defined properties. Changes made with this API are stored in a file named configoverlay.json. This file should only be edited with the API, but will look like this example:

{"userProps": {
    "dih.db.url": "jdbc:oracle:thin:@localhost:1521",
    "dih.db.user": "username",
    "dih.db.pass": "password"}}

For more details, see the section Config API.

solrcore.properties

If the configuration directory for a Solr core contains a file named solrcore.properties that file can contain any arbitrary user-defined property names and values using the Java properties file format. Those properties can then be used as variables in other configuration files for that Solr core.

For example, the following solrcore.properties file could be created in the conf/ directory of a collection using one of the example configurations, to override the lockType used.

#conf/solrcore.properties
solr.lock.type=none

User-Defined Properties in core.properties

Every Solr core has a core.properties file, automatically created when using the APIs. When you create a SolrCloud collection, you can pass through custom parameters by prefixing the parameter name with property.name as a parameter.

For example, to add a property named "my.custom.prop":

http://localhost:8983/solr/admin/collections?action=CREATE&name=gettingstarted&numShards=1&property.my.custom.prop=edismax

curl -X POST -H 'Content-type: application/json' -d '{"create": {"name": "gettingstarted", "numShards": "1", "property.my.custom.prop": "edismax"}}' http://localhost:8983/api/collections

This will create a core.properties file that has at least the following properties (others omitted for brevity):

#core.properties
name=gettingstarted
my.custom.prop=edismax

The my.custom.prop property can then be used as a variable, such as in solrconfig.xml:

<requestHandler name="/select">
  <lst name="defaults">
    <str name="defType">${my.custom.prop}</str>
  </lst>
</requestHandler>

Implicit Core Properties

Several attributes of a Solr core are available as "implicit" properties that can be used in variable substitution, independent of where or how the underlying value is initialized.

For example, regardless of whether the name for a particular Solr core is explicitly configured in core.properties or inferred from the name of the instance directory, the implicit property solr.core.name is available for use as a variable in that core’s configuration file:

<requestHandler name="/select">
  <lst name="defaults">
    <str name="collection_name">${solr.core.name}</str>
  </lst>
</requestHandler>

All implicit properties use the solr.core. name prefix, and reflect the runtime value of the equivalent core.properties property: