solr comes with an example schema and scripts for running on Jetty. The next section describes some of the details of how things work “under the hood,” and covers running multiple Solr instances and deploying Solr using the Tomcat application manager.
How Solr Works with Tomcat
The two basic steps for running Solr in any Web application container are as follows:
- Make the Solr classes available to the container. In many cases, the Solr Web application archive (WAR) file can be placed into a special directory of the application container. In the case of Tomcat, you need to place the Solr WAR file in Tomcat’s webapps directory. If you installed Tomcat with Solr, take a look in tomcat/webapps:you’ll see the solr.war file is already there.
- Point Solr to the Solr home directory that contains conf/solrconfig.xml and conf/schema.xml. There are a few ways to get this done. One of the best is to define the solr.solr.home Java system property. With Tomcat, the best way to do this is via a shell environment variable, JAVA_OPTS. Tomcat puts the value of this variable on the command line upon startup. Here is an example:
Port 8983 is the default Solr listening port. If you are using Tomcat and wish to change this port, edit the file tomcat/conf/server.xml in the Solr distribution. You’ll find the port in this part of the file:
Modify the port number as desired and restart Tomcat if it is already running.
|Modifying the port number will leave some of the samples and help file links pointing to the default port. It is out of the scope of this reference guide to provide full details of how to change all of the examples and other resources to the new port.|
Running Multiple Solr Instances
The standard way to deploy multiple Solr index instances in a single Web application is to use the multicore API described in Using Multiple SolrCores.
An alternative approach, which provides more code isolation, uses Tomcat context fragments. A context fragment is a file that contains a single <context> element and any subelements required for your application. The file omits all other XML elements.
Each context fragment specifies where to find the Solr WAR and the path to the solr home directory. The name of the context fragment file determines the URL used to access that instance of Solr. For example, a context fragment named harvey.xml would deploy Solr to be accessed at http://localhost:8983/harvey.
In Tomcat’s conf/Catalina/localhost directory, store one context fragment per instance of Solr. If the conf/Catalina/localhost directory doesn’t exist, go ahead and create it.
Using Tomcat context fragments, you could run multiple instances of Solr on the same server, each with its own schema and configuration. For full details and examples of context fragments, take a look at the Solr Wiki: http://wiki.apache.org/solr/SolrTomcat.
Here are examples of context fragments which would set up two Solr instances, each with its own solr.home directory:
Deploying Solr with the Tomcat Manager
If your instance of Tomcat is running the Tomcat Web Application Manager, you can use its browser interface to deploy Solr.
Just as before, you have to tell Solr where to find the solr home directory. You can do this by setting JAVA_OPTS before starting Tomcat.
Once Tomcat is running, navigate to the Web application manager, probably available at a URL like this:
You will see the main screen of the manager.
To add Solr, scroll down to the Deploy section, specifically WAR file to deploy. Click Browse… and find the Solr WAR file, usually something like dist/apache-solr-3.x.0.war within your Solr installation. Click Deploy. Tomcat will load the WAR file and start running it. Click the link in the application path column of the manager to see Solr. You won’t see much, just a welcome screen, but it contains a link for the Admin Console.
Tomcat’s manager screen, in its application list, has links so you can stop, start, reload, or undeploy the Solr application.