Solr is deployed as a simple WAR (Web application archive) file that packages up the servlet, JavaScript files, code libraries, and all of the other bits that are required to run Solr. Therefore, Solr can be deployed into any Java EE Servlet container that meets the Servlet 2.4 specification, such as Apache Tomcat, JBoss, and GlassFish, as well as Jetty, which by default ships with Solr.
The key thing to resolve when working with Solr and the various Servlet containers is that technically you are supposed to compile a single WAR file and deploy that into the Servlet container. It is the container's responsibility to figure out how to unpack the components that make up the WAR file and deploy them properly. For example, with Jetty, you place the WAR file in /webapps, but when you start Jetty, it unpacks the WAR file in /work as a subdirectory, with a somewhat cryptic name that looks something like Jetty_0_0_0_0_8983_solr.war__solr__k1kf17.
In contrast, with Apache Tomcat, you place the solr.war file into /webapp. When you either start up Tomcat, or Tomcat notices the new .war file, it unpacks it into /webapp. Therefore, you will have the original /webapp/solr.war and the newly unpacked (exploded) /webapp/solr version. The Servlet specification carefully defines what makes up a WAR file. However, it does not define exactly how to unpack and deploy the WAR files, so your specific steps will depend on the Servlet container you are using. For information specific to various servlet containers, see Solr's wiki at http://wiki.apache.org/solr/SolrInstall. If you are not strongly predisposed to choosing a particular Servlet container, then choose Jetty, which is a remarkably lightweight, stable, and fast Servlet container. It is what Solr is developed against, and is the least likely to give you problems. Note that, in Solr 5, the need for a servlet container to host Solr will be removed, and Solr will run in it's own process, like MySQL or any other server process does, using the installation and start scripts. For more information, refer to the following wiki pages: https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production#TakingSolrtoProduction-ServiceInstallationScript and https://cwiki.apache.org/confluence/display/solr/Solr+Start+Script+Reference.
Probably the biggest thing that trips up folks deploying into different containers is specifying the solr.home property. Solr stores all of its configuration information outside of the deployed webapp, separating the data part from the code part for running Solr. In the example app, while Solr is deployed and running from a subdirectory in /work, the solr.home directory is pointing to the top level /solr directory, where all of the data and configuration information is kept. You can think of solr.home as being analogous to where the data and configuration is stored for a relational database such as MySQL. You don't package your MySQL database as part of the WAR file, and nor do you package your Lucene indexes.
By default, Solr expects the solr.home directory to be a subdirectory called /solr in the current working directory as defined by the Servlet container. With both Jetty and Tomcat you can override that by passing in a JVM argument that is somewhat confusingly namespaced under the solr namespace as solr.solr.home:
-Dsolr.solr.home=/Users/epugh/solrbook/solr
Alternatively, you might find it easier to specify the solr.home property by appending it to the JAVA_OPTS system variable. On Unix systems, you would do the following:
>>export JAVA_OPTS="$JAVA_OPTS - Dsolr.solr.home=/Users/epugh/solrbook/solr"
Alternatively, lastly, you might choose to use JNDI with Tomcat to specify the solr.home property as well as where the solr.war file is located. JNDI (Java Naming and Directory Interface) is a very powerful, if somewhat difficult to use, directory service that allows Java clients such as Tomcat to look up data and objects by name.
By configuring the stanza appropriately, we were able to load up the solr.war file and home directory from the example configuration shipped with Jetty using Tomcat instead. The following stanza went in the /apache-tomcat-6-0.18/conf/Catalina/localhost directory that we downloaded from http://tomcat.apache.org, in a file called solr.xml:
<Context docBase="/Users/epugh/solr_src/example/webapps/solr.war" debug="0" crossContext="true" > <Environment name="solr/home" type="java.lang.String" value="/Users/epugh/solr_src/example/solr" override="true" /> </Context>
We had to create the ./Catalina/localhost subdirectories manually.
Tip
Note the somewhat confusing JNDI name for solr.home is solr/home. This is because JNDI is a tree structure, with the home variable being specified as a node of the Solr branch of the tree. By specifying multiple different context stanzas, you can deploy multiple separate Solr instances in a single Tomcat instance.