What's New in Tomcat 5

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:

$ ant -projecthelp

Buildfile: build.xml

Main targets:



 clean     Removes build directory

 compile   Compile web application

 deploy    Deploy web application

 reload    Reload web application

 start     Start web application

 stop      Stop web application

 undeploy  Undeploy web application



Default target: compile

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

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.

O'Reilly & Associates published Tomcat: The Definitive Guide in June 2003.

• Sample Chapter 6, "Tomcat Security," is available free online.

• You can also look at the Table of Contents, the Index, and the full description of the book.

• For more information, or to order the book, click here.

Return to ONJava.com.