Using Tomcat with eZ Find

by Ivo Lukač -

Few years back when eZ Find (on github) showed up we soon started to deploy it on almost every site we were implementing. The hearth of eZ Find is Solr - a Lucene based java search engine with REST interface. Bundled wit eZ Find comes Jetty for running the whole java stack with one command to keep the usage as simple as possible. We switched to Apache Tomcat instead. Learn why.

We even worked with the ezlucene extension which was a kind of predecessor of eZ Find.

The hearth of eZ Find is Solr - a Lucene based java search engine with REST interface. Bundled wit eZ Find comes Jetty for running the whole java stack with one command to keep the usage as simple as possible. And we used Jetty for a while but soon hit an issue. Jetty had the problem with UTF-8 encoding, can’t remember what it was but it didn’t use all Croatian letters well. So we switched to Apache Tomcat instead. In the meanwhile Jetty probably resolved that issue but we discovered some other good things with Tomcat.

Grumman_F-14_Tomcat

Surely there are many differences between Jetty and Tomcat in general, but I found a lot of contradicting information on the web regarding performance and system level stuff. In my experience Tomcat has a bit more configuration and tuning capabilities, which are important if you have a multi site setup.

The multi site setup is possible with Jetty too but a bit awkward.  If you need more instances  (for example different versions of solr or you just want to separate it ) you would need to set new port for each one, etc.

Multi site setup with tomcat

For live environment after tomcat 5.5 or higher is installed and running, there is only one configuration file to add. Go to
/etc/tomcat/Catalina/localhost folder and create a myezfind.xml file:

<?xml version="1.0" encoding="UTF-8" ?>
<Context docBase="/[PATH_TO_WEB_ROOT]/extension/ezfind/java/webapps/solr.war" debug="0" crossContext="true">
<Environment name="solr/home" type="java.lang.String" value="/[PATH_TO_WEB_ROOT]/extension/ezfind/java/solr" override="true"/>
</Context>

You then need to do all other stuff you usally do:

  • configure solr.ini with port etc (Tomcat is usually set to 8080 by default but that can be changed easily)
  • set writing permissions in java/data folder
  • run the indexing script

With this configuration every eZ Publish instance has the index separated.

On the development server where 50+ web sites are held we have even less instances. This is achieved by having only one instance of solr for each ezfind version.

How we do it?

  • we have  ezfind installations deployed outside an ezpublish web root for each version. Basically only solr is there, not the whole ezfind
  • we have 3 instances in tomcat pointing to those solr folders (as explained already)
    http://dev.server.local:8080/ezfind23
    http://dev.server.local:8080/ezfind24
    http://dev.server.local:8080/ezfind25
  • for deploying a new web on the dev server we just need to point the right url in sorl.ini and run the indexing script.
  • installation_id parameter is taking care of dividing the results for each web

2 remarks:

  • do not use --clean-all when running the index script as you will wipe out all data from one index
  • if you duplicate a web by copying database make sure to delete the ezfind_id row in ezsite_data to reset the installation id

autoDeploy="false"

One warning for the end. There is a very interesting Tomcat option for auto-deploying which is enabled by default. This enables that all changes you make to the configuration files are executed instantly. Although it does make some sense in some situations, we disabled it on dev server. Reason? If you by any chance change the folder pointed from tha Catalina xml file (e.g upgrading ez installations, etc.) tomcat will delete the xml configuration file :) Scary, if you don’t know what is happening (like I didn’t know first time configuring Tom the cat)

Comments

This site uses cookies. Some of these cookies are essential, while others help us improve your experience by providing insights into how the site is being used.

For more detailed information on the cookies we use, please check our Privacy Policy.

  • Necessary cookies enable core functionality. The website cannot function properly without these cookies, and can only be disabled by changing your browser preferences.