Solr.xml

Deprecated and unsupported as of 5.0, see Solr.xml 4.4 and beyond

To enable support for dynamic SolrCore administration, place a file named solr.xml in the solr.home directory. Here is an example solr.xml file:

<solr persistent="true" sharedLib="lib">
 <cores adminPath="/admin/cores">
  <core name="core0" instanceDir="core0" />
  <core name="core1" instanceDir="core1" />
 </cores>
</solr>

You can also specify properties in solr.xml which can be used in the solrconfig.xml and schema.xml files.

<solr persistent="true" sharedLib="lib">
 <property name="snapshooter" value="/home/solr-user/solr/bin/snapshooter.sh" />
 <cores adminPath="/admin/cores">
  <core name="core0" instanceDir="core0">
    <property name="dataDir" value="/data/core0" />
  </core>
  <core name="core1" instanceDir="core1" />
 </cores>
</solr>

The properties can be container scope (i.e. specified after <solr> but outside of a <core> element) in which case it is automatically inherited by each core. Therefore, they can be used in any of the cores' configuration files.

The properties can also be defined in a core's scope (inside the <core> element) in which case they can be used only in that core's scope. If a property by that name already exists in the container scope then it will be overridden.

Besides them, a few properties are automatically added in the core scope. They are:

Such properties can be used inside solrconfig.xml and schema.xml files by specifying an expression with optionally, a default value.

// Without a default value
${snapshooter}
// With a default value
${snapshooter:./solr/bin/snapshooter.sh}

The above expression will evaluate to the value specified in solr.xml for the property name "solr.snapshooter". If no value is defined in solr.xml, it will check if a system property by that name exists otherwise it will use the specified default value. If no default value is specified, a runtime exception will be thrown and the core may fail to startup.

solr

The <solr> tag accepts two attributes:

cores

The <cores> tag accepts the following attributes:

import org.apache.solr.handler.admin.CoreAdminHandler ;

class MyAdminHandler extends CoreAdminHandler { 
    
  /**
   * @return true, if the changes need to be persisted by the CoreContainer. (use only if solr.xml would be changed because of this action. )
   *         false, otherwise.   (Use this if unsure or having a read-only access to the CoreContainer like collecting statistics)
   * 
   */ 
  protected boolean handleCustomAction(SolrQueryRequest req, SolrQueryResponse rsp) {
     CoreContainer container = super.getCoreContainer(); 
     SolrCore mycore1 = container.getCore("core1");
     SolrCore mycore2 = container.getCore("core2");
     SolrParams params = req.getParams();
     String a = params.get( CoreAdminParams.ACTION );
     if (a.equalsIgnoreCase("mystat"))  {
         // TODO: populate 'rsp' as necessary. 
      } 
  } 
}

class MyAdminHandler extends CoreAdminHandler { 
    //Available for override , but unnecessary except for the rare case. 
     protected boolean handleAliasAction(SolrQueryRequest req, SolrQueryResponse rsp) ; 
     protected boolean handleCreateAction(SolrQueryRequest req, SolrQueryResponse rsp) ; 
     // etc. 
}

The <core> tag accepts the following attributes:

property

The <property> tag accepts two attributes:

solr.xml Permissions

It is important to note that persistent=true functionality 'replaces' solr.xml it does not edit it. This means that the directory the file is in needs to allow the web server to replace the file. If the permissions are set incorrectly it will give 500 errors and throw IOExceptions. Additionally, all comments are wiped from the file on save.

Example

Solr ships with an example running two cores together setup. To run this configuration, start jetty in the example/ directory using:

java -Dsolr.solr.home=multicore -jar start.jar

This will start solr running two cores: core0, and core1. To access each core, try:

To access the admin pages for each core visit: