Refactored Web Application Deployer Subsystem

Another enhancement to Tomcat 5 is that its deployer subsystem has been refactored to offer better modularity,
and less troublesome deployment/undeployment/redeployment semantics. A
standalone deployer program has also been added. Let's look at the deployer subsystem first.

Tomcat 4's configuration system offered some modularity in the form of
deployment context fragments. These were XML configuration files that contained
a single <Context> element and everything nested within it.
If the deployer found one in the CATALINA_HOME/web apps directory,
it would deploy that context (web app) the same as if it had been configured in
Tomcat's server.xml file. This was helpful because any changes to
the server.xml cannot be reread until Tomcat is restarted, while
context XML fragment files can be reloaded at any time. But, the administrator
didn't have any fine-grained way to control which <Host> they
were deployed into, or which <Engine> (for those who have
multiple <Engine>s configured -- probably not many).

To add better scoping control of the context fragments, and to consolidate
Tomcat's configuration files in the CATALINA_HOME/conf directory,
Tomcat 5 now supports placing the context fragments in a
CATALINA_HOME/conf/[Enginename]/[Hostname]/
directory. For example, if your Engine is named Catalina, and you have a Host
named www.example.com, then you can place context XML fragments into the
CATALINA_HOME/conf/Catalina/www.example.com/ directory. If you have
multiple <Host>s, each of them has its own directory,
separating its config files from other <Host>s. Reloading
the context fragments in Tomcat 5 works the same as in Tomcat 4, they're just in
a different file system location.

Many of the <Host> deployment attributes have been
renamed, or have had their behavior changed in Tomcat 5. Mainly this was to
rename ambiguously named attributes, but it was also to make
the deployment and redeployment behavior a bit more desirable. For example, the
Tomcat 4 <Host> attribute named liveDeploy has been renamed
autoDeploy in Tomcat 5, and the Tomcat 4 attribute named autoDeploy has been
renamed deployOnStartup in Tomcat 5. In short, Tomcat 4's
<Host> configuration elements in server.xml are
not compatible with those of Tomcat 5. Compare the Tomcat 4.1 Host configuration reference page with the Tomcat 5.0 Host configuration reference page in order to migrate your configs.

Standalone Deployer

As of Tomcat 5, a new standalone web app deployer is included. By standalone
I mean that it isn't bundled as part of Tomcat but as a separate package released alongside of Tomcat. This deployer is actually just an Apache Ant build file that uses some custom Ant tasks to do things to web applications, like:

Compile the JSPs

Validate the deployment descriptor using XML schema validation

Deploy it into Tomcat

Redeploy a new version

Undeploy a web app

Reload a web app without redeploying it

Start a web application

Stop a web application

List the context paths of all currently installed web applications of a specified virtual host

List the available global JNDI resources in Tomcat

List the available roles and their descriptions

But not all of these tasks are used in the deployer's build file. Here's
output from the build file showing the public targets that it offers:

Almost all of the custom Ant tasks that come with the deployer were already
included in Tomcat 4.1, but they weren't packaged as a component separate from
Tomcat. Mainly, this deployer serves as a rough but functional example of how to
instrument an Ant build system to perform these functions.

Better Support for JMX

Tomcat 5.0 has substantially better JMX instrumentation than Tomcat 4.1. How
much better? I did a direct comparison between the two versions by counting all
of the MBeans, attributes of the MBeans, and operations (method calls) exposed
by the MBeans in each version of Tomcat. Here are the numbers as of this
writing:

Number of items exposed through JMX

Tomcat Version

MBeans

Attributes

Operations

4.1.30

52

282

79

5.1.18

68

391

148

As you can see, Tomcat 5.0 adds a significant number of attributes and
operations that are exposed via JMX. Basically all of Tomcat's internal objects
are exposed as MBeans in both versions, so both do a great job of exposing
enough objects as MBeans. For the purpose of monitoring, the number of
attributes is the most important: Tomcat 5.0 exposes 109 more of them than
Tomcat 4.1. For the purposes of management/administration and dynamic
configurability, operations are the most important. Tomcat 5.0 really shines
here, exposing 69 more operations -- almost double that of Tomcat
4.1.

If you download a Tomcat 4.1 binary release, it comes bundled with the open
source MX4J version 1.1.1 implementation of the JMX 1.1 Specification. This
version of JMX does not include the JMX Remote API (JSR 160), since the JMX Remote API only works with JMX 1.2 implementations. This means that there is no
standard network protocol for managing and monitoring Tomcat 4.1 via the
network. The Tomcat 5.0 binary release comes bundled with Sun's JMX 1.2
reference implementation, along with Sun's JMX Remote API 1.0 reference
implementation (although it could just as easily be bundled with the MX4J 2.0 implementation of JMX 1.2 and the JMX Remote API 1.0 -- it's still in beta but it works great).

As it turns out, both of these versions of Tomcat can be compiled against a
JMX 1.2 implementation, and both can run with them. But, if you're not building
your own Tomcat (as you'll see in the next section, it's easier to do with
Tomcat 5), then Tomcat 4 doesn't come with JMX 1.2 and Tomcat 5 does. But Tomcat 5 doesn't yet offer any way of turning on a JMX Remote API connection
server. That's coming soon for Tomcat 5, but as of this writing it isn't
included yet.

Improved Tomcat Build System

Tomcat 5's build system is quite a bit more automated than that of Tomcat 4.
It has also been cleaned up in many ways.

Anyone who has tried to build Tomcat 4 can tell you that it isn't easy to do
-- you have to download and carefully install a swarm of jar files from many
different web sites, pull down Tomcat 4's source code either via a source
snapshot archive or from CVS, set some paths in a properties file, and then try
to build it. Most people do all that only to have the build fail due to either
missing jar files or due to improper jar file versions (despite properly
following directions from Tomcat 4's BUILDING.txt file). Tomcat's dependencies changed frequently in Tomcat 4; the BUILDING.txt file wasn't always kept up-to-date with the exact version numbers that were necessary; and the paths where the build expected to find them are
exact and inconsistent. The Tomcat committers did quite a bit of work to keep
everything up-to-date and building cleanly, but assembling a working build
environment from scratch was still mainly a manual, error-prone process.

Tomcat 5's build system, on the other hand, has been automated so that it can
assemble its own build environment, all except for installing the JDK and Apache
Ant (they're using version 1.6). Just download the top-level build file and invoke the default target and away it goes! It will do all the pulling and installing of the jars and Tomcat 5 source code, configure the build, and then start building Tomcat 5. Of course, you may want to make your own custom-build properties file if you have special build-configuration needs -- if you have no special needs then why not just use a binary release? See this page for info on customizing the build. Regardless, the build is so automated it feels like it's on autopilot.

Session Clustering Code as a Module

Tomcat 4 did not implement nor include any servlet session-clustering, except
for some old, mainly broken code that was once a valiant attempt at implementing
session-clustering via IP multicast. A new implementation of session-clustering
was implemented for Tomcat, and worked with Tomcat 4.1 as an add-on feature, but
was never included nor bundled with Tomcat 4.1.

Tomcat 5 includes this newer session-clustering implementation as a module.
The default server.xml configuration file contains some text about
how to configure it, but it is turned off by default as most people only run one
instance of Tomcat and do not use session-clustering. But it's included in
Tomcat 5 for those who want it.

This session-clustering implementation barely worked for Tomcat 4, but has
been significantly refactored for Tomcat 5. Tomcat 5.0.16 included lots of
improvements over Tomcat 4, but then many more improvements were made after
5.0.16, and I recommend only using version 5.0.18 and higher if you want to use
session-clustering! Many important performance enhancements and serious bug
fixes have been applied since version 5.0.16.

For background information about how this kind of session-clustering works,
you might want to see our book Tomcat: The Definitive Guide (O'Reilly). In Chapter 10, Tomcat Clustering we go over many details about distributed web applications and how servlet session-clustering works. Also, see the Cluster How-to for information specific to this session-clustering implementation.

This clustering module is the first (and so far the only) Tomcat 5 module
included in the distribution. It will be interesting to see what other modules
get added to Tomcat 5 in the future.

Increased JSP Tag Library Efficiency via Tag Pooling and Tag Plug-ins

Since JSP is popular, and JSP custom tag libraries are becoming popular,
Tomcat needs to keep these features efficient and scalable by implementing ways
to speed things up behind the scenes in the implementation of the JSP engine. To
avoid unnecessary object instantiation and garbage creation, which are costly in
terms of time and memory, two techniques are being used in Tomcat 5 to speed
things up: tag pooling and tag plug-ins.

Tag pooling is much like servlet pooling, or any other object pooling, for
that matter. The idea is that you may have many request threads at once that
each need the same kind of object, and that object does not need to be stateful
across more than one request. In that case, the server can instantiate a pool of
them that it can draw from instead of instantiating new ones all the time. When
a request is done with the object, it gets returned to the pool after any
request state is first purged.

Tomcat 5's JSP engine, Jasper 2, can pool JSP tag objects this way, which
speeds things up nicely. Tomcat 4.1 also had an early implementation of tag
pooling, but the implementation in Tomcat 5 is more mature.

Another feature of Jasper 2 is "tag plug-ins," not to be confused with tag
files (discussed earlier in this article). Tag plug-ins are not a JCP
standard, but instead something specific to Tomcat 5's JSP implementation. In
short, it is a modular way of optimizing the Jasper 2 JSP engine to render a
custom JSP tag library as fast as possible. Probably the best explanation about
it that I could find on the Net (other than the source code) is the original tomcat-dev mailing list thread where the concept was first introduced.

Tomcat 4 does not implement tag plug-ins. Tomcat 5.0 is the first to do so.
This means that Tomcat 5 should be faster at rendering some JSP pages than
Tomcat 4, especially when one or more tag libraries being used is accompanied by
tag plug-ins.

The Balancer Web App

Also new in Tomcat 5.0 is the Balancer web app, a rules-based load balancer
implemented as a web application. Balancer is useful for anyone who doesn't
already own a hardware load balancer (or doesn't want to spend the money to buy
one), and who needs to load balance across more than one Tomcat instance.

There are many ways to load balance HTTP requests, and not all methods are
right for your site. But Balancer is a free, pure-Java implementation of a
software load balancer that uses infrastructure that Tomcat users already have
running: Tomcat. It doesn't do low-level TCP NAT or TCP tunneling, but instead
load balances via HTTP redirects.

In Tomcat 5.0.16, Balancer is a new implementation and lacks many features people will want. And it's probably not a good solution for load-balancing
requests for very high-traffic web sites. But the Balancer web app is useful for
some people as it existed in Tomcat 5.0.16, and is included in part so that it
is possible to install and configure a 100 percent Java cluster using only what comes
with Tomcat 5.0. With the inclusion of the Balancer web app, Tomcat alone now
implements a clustered servlet and JSP container, implemented in pure Java. See
the Balancer How-to for details about how to use it.

Conclusion

Tomcat 5.0 contains many substantial updates and improvements over Tomcat
4.1. Many of the underlying technologies that Tomcat builds upon have been
updated, enabling Tomcat 5 to offer a wider range of solutions and features to the
administrator and developer. This, combined with many
performance enhancements and a smaller memory footprint during heavy loads means
that Tomcat 5 does a better job with the same web apps than does Tomcat 4. Tomcat 5 is
also more manageable, more easily monitored, and is easier to build.
Tomcat 5.0 is production-ready now. The Tomcat community tested many releases of
Tomcat 5 before it was voted stable late last year. I recommend you consider
upgrading to Tomcat 5.0.

Jason Brittain
is a Senior Software Engineer at Symantec Corporation's Network and Gateway Security Solutions Team, working on the AntiSpam
product. He has contributed
to many Apache Jakarta projects, and has been an active open source software developer for several years.