Setting up Solr 4.0 on Tomcat 7.0.28

Generally every user centric application requires a Search capability. With Google easily leading the Search domain, user expectations are generally high when they come to a web-application and perform a search. If giving user's the Google experience is not possible, consider Apache's Solr  which is a popular, open-source Java based search tool that runs Lucene under hood.

While Solr comes packaged with Jetty and has a basic tutorial, that provides pointers on its different features, setting up the tool to run within an existing Apache Tomcat instance can require a bit of effort as there are several files and folders and it is not immediately clear which files control the configuration of the tool. This post will document the various steps involved in setting up Solr to run with Apache Tomcat 7.0.28 on a Windows server.

Step 1 : Download a copy of Solr and unzip it  to apache-solr-4.0.0.

Step 2: Create new directory which will be the home of Solr c:\solr_home and copy the following files and folders into it.  ( You will find  them within  the unzipped apache-solr-4.0.0 folder).
bin
collection1
solr.xml
zoo.cfg

collection1 is an existing example which we will load up into our Tomcat.Within the directory collection1, you'll find two other folders conf & data. Just verify that these are present.

Now we'll connect Solr to Tomcat.

Step 3:  Copy the apache-solr-4.0.0.war (which you will find in apache-solr-4.0.0\dist)  into your Tomcat web-apps directory.

Step 4:  Finally, the last step. Tell Solr where the existing search configuration files for collection1 reside.
To do this add the location of the Solr Home directory to your Tomcat JAVA_OPTS. I am setting this value in the setenv.bat file and the declaration looks like this :

set JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF-8 -server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -Dsolr.solr.home=C:/solr_home

Step 5:  Start Tomcat and browse to your loaded Solr instance at http://localhost:8080/apache-solr-4.0.0/#/ You should see the Solr Admin screen as below :

Solr Admin Console for Collection 1

To check if Solr has been configured and set up correctly, select collection1 in the left hand side bar and select the query option. Enter 'solr' in the textbox labelled 'q' as shown in the screenshot below.

Default Search Interface

On submitting the query, one result is returned by Solr. On clicking on the result link, the record is displayed as an XML.

Search Result for 'Solr'

In the next post, I'll document the steps of integrating Solr with an existing web-application which is running on the same Tomcat instance with a MySQL back-end.

Creating an executable jar with a Maven plugin

While there are several non Maven based ways of creating an executable Jar that includes all required dependencies, Maven as a build tool offers three plugins for directly achieving this result. The Maven Assembly plugin is the first of these options. Creating an executable jar is just one of the objectives of the Assembly plugin. It can be used to create distributions in various file formats such as the zip format.

To configure the Maven Assembly plugin to create an executable jar with all required dependencies included, add the following configuration definition to your pom.xml in the build section.

   ..........
   
   maven-assembly-plugin
   2.4
   
     false
         standalone-${artifactId}-${version}
     
       jar-with-dependencies
     
     
        
           com.data.john.MainClass
           true
        
     
   
     
        
           make-assembly 
           package
           
              single
           
        
    
 
.............
.............

The second option is the Maven Shade plugin. The primary objective of this plugin is to create an executable jar and so it is much more suited for this use case. The configuration setup is as follows:

.................   

    org.apache.maven.plugins
    maven-shade-plugin
    2.0
    
        
             package
            
                 shade
            
            
            standalone-${artifactId}-${version}
            
              
              *:*
              
               META-INF/*.SF
               META-INF/*.DSA
               META-INF/*.RSA
              
             
            
            
                 
                    com.data.masker.controller.MaskerApp
                
            
           
        
    

..............

While tossing up between the Assembly and the Shade plugin, It should be mentioned that with using Maven Assembly, you run the risk of overwriting files with similar namespaces. These scenarios can be better handled using the Shade plugin, that provides more granular control over the build process by merging files with the same name instead of overwriting them.
Finally, this discussion would not be complete without mentioning the Maven Jar plugin, yet another way of  creating an executable jar with some use case examples given here.

All three options can be invoked using the mvn package call.