Tomcat Servlet Container for ArcIMS
Installing ArcIMS is easy. However, when setting up ArcIMS, many
people encounter difficulties not with ArcIMS itself, but with the
servlet engine and the web server.
This can be made easier using a commercial servlet engine. Two
supported commercial servlet engines are New Atlanta ServletExec and
Allaire JRun. Both are good products. However, on most platforms, ESRI
also supports a free servlet engine, Jakarta Tomcat. Tomcat is actually
the reference implementation of the servlet and JSP standards.
Tomcat has its own set of difficulties: until very recently, the
installation procedure requires manual editing of configuration files.
Although this is still common on UNIX, those coming from a Windows
background will see this as a throwback to the dark ages. The manual
configuration is error-prone, and many people have difficulty with this.
Even after many successful Tomcat installs, I occasionally run into a
configuration where something goes wrong. However, over time I have
refined an installation procedure that makes this much easier and less
error-prone, with lots of checkpoints to make sure everything is
I have packaged a copy of Jakarta Tomcat 3.2.4, configured to work out
of the box with ArcIMS 3.1, 4.0, or 4.0.1. This Tomcat configuration does
not require anything that is not included on the ArcIMS CD-ROM, or with
your web server. In particular, it does not require the Java 2 SDK to be
installed on your server; it can use the same Java Runtime that is
installed as part of ArcIMS.
Tomcat 3.2.4, preconfigured for Jikes and ArcIMS]
Just extract to C:\Tomcat, and follow the directions in
This preconfigured binary was temporarily unavailable due to bandwidth
restrictions. Thanks to Richard Beck of University of Cincinatti,
McMicken College of Arts and Sciences, Department of Geography for
providing FTP space so that it could be published again.
Java Compiler and JSP Support
To support JSP, a Java compiler is required. Normally this means you
need to install the Java 2 SDK (20-30MB) and configure Tomcat to use that
as its Java runtime. Instead, this version of Tomcat is modified so that
its JSP handler uses the IBM Jikes Compiler. Like Tomcat, Jikes is free
software. Jikes is much smaller than the Java SDK, and is included in the
package. Actually many organizations recommend the use of Jikes in a
production environment, since its performance is reportedly much better
than the Java SDK's javac compiler.
Later versions of Tomcat
Tomcat has since gone through several releases, including 3.3, 4.0,
and 4.1. Until recently, none of this has mattered to ESRI customers
because 3.2.x remained the latest supported version. (However,
unofficially, many people reported success with 4.0.x.) Now, Tomcat 4.0.5
has become a supported platform for ArcIMS 4.0 on Apache 2 or IIS 5. At
ArcIMS 4.0.1, Tomcat 4.0 and 4.1 are both supported.
My advice in the past (prior to this new support) has been that, if
you want to use Tomcat as your ArcIMS Servlet Container, you should stick
to 3.2.x for production work, so that you can be supported. However, with
the recent changes in policy, you can upgrade and remain supported. If
you choose to go that route, please be aware, Tomcat 4.0.5 contains a known
security issue. Proceed with caution, and remember to apply the
If you are upgrading to Apache 2, you must upgrade your Tomcat to at
least 4.0.5 to be running an ESRI-supported configuration. (You can also
use my Tomcat 3.2.4 installer with Apache 2. It works fine; ESRI
technical support just isn't set up to run that configuration
in-house.) Since the Apache group has always considered the Win32 port of
Apache 1.3.x to be "beta" quality, and says Apache 2 is as
solid on Win32 as it is on Unix, this could be a compelling reason to
upgrade both Apache and Tomcat.
Support for JSP taglibs might be another good reason to upgrade.
Tomcat 3.x supports JSP 1.1; Tomcat 4.x supports JSP 1.2. The JSP
Standard Tag Library requires JSP 1.2, and therefore Tomcat 4. I think
JSP is a horrible way to write server-side code, but taglibs make it
slightly less bad.
Although there are good reasons to upgrade from Apache 1.3.x and
Tomcat 3.2.4, performance is not one of them. That's not to say
Tomcat 4.x won't perform better - by most reports, it will. Tomcat 4
is engineered to perform better than Tomcat 3.2.x, but
ArcIMS's Application Server architecture means that most of the work
happens outside of the servlet container. And let's face it: when
you're generating dynamic maps from a live enterprise geodatabase,
the servlet container is not going to be the bottleneck, even if it were
doing more than just dispatching requests to the App Server. So the
effect of Tomcat 4's higher performance won't be very
The Tomcat 3.2.4 / Jikes installation procedure has been updated for
procedure for ArcIMS 4.0.1. Actually, with 4.0.1, Tomcat 3.2.3 is the
officially sanctioned release in the Tomcat 3.2 series (as opposed to a
more general 3.2.x for previous versions of ArcIMS), but considering that
Tomcat 3.2.4 is a bugfix release, and Jakarta project strongly recommends
those using Tomcat 3.2.3 should upgrade, I will not be downgrading.
Don't worry, I think they're mainly concerned that you might be
running 3.2.1 or 3.2.2, which have more serious bugs. 3.2.4 has been
working flawlessly for me in many, many installations.
With ArcIMS 4.0.1, ESRI is going to support Tomcat 4.1 for the first
time. I may eventually update my setup procedure to take advantage of
this, and support Tomcat 4.1 on Apache 2 as well as IIS 5. I run Apache 2
and IIS 5 on my workstation, for testing and development, and it would be
good if I could run that with a supported version of Tomcat. I hope ESRI
will support Tomcat 4.1.18 or later by the time I get around to this.
I have noticed that Tomcat 4.1 has good, solid support for Jikes as a
servlet engine, so the configuration changes will be much simpler. 4.1
also has an installer, but that works against the JDK. That is actually
not a recommended configuration at all for Tomcat, since the
Jakarta group reports known memory leaks when compiling JSPs that way.
(The leaks aren't Tomcat's fault - they are in the javac - but
still they provide yet another reason to use Jikes.)