What's New in Tomcat 5by Jason Brittain, coauthor of Tomcat: The Definitive Guide
On Dec. 3, 2003, the Apache Tomcat developers released their latest version of the popular open source Java servlet and JSP container, version 5.0.16, as the first stable release of Tomcat 5. If you're already running Tomcat 4, you'll be happy to know that Tomcat 5 is easy to migrate to, and has many new features that make it advantageous to upgrade. In this article, we'll take a look at the latest features in Tomcat 5. To start things off, we'll offer some insight into the goals established for version 5.0, which in many cases impacted the development of these new additions. In reviewing 5.0's new features, we found it helpful to look back at how they evolved, so we'll very often provide a nod to their roots in versions 4.1 and earlier. But first, let's take a look at the significance of this latest version numbering.
Defining Version 5.0
Tomcat 5.0 is, of course, the next major refactoring of Tomcat since version 4.1. The major version number of Tomcat is incremented each time the Java Servlet and JSP specifications have a new final release, hence Tomcat 5 corresponds with the final release of the Servlet 2.4 and JSP 2.0 specifications.
All new development will now occur on the Tomcat 5.0 source code branch, or on one of its future sub-branches. The Tomcat committers could decide to apply new code with new features to Tomcat 4.1's source, but that's only likely to be a backport of features that are already implemented in Tomcat 5. If critical security flaws are fixed in Tomcat 5 that also apply to Tomcat 4.1's code, for example, those will probably all be backported.
Tomcat 5.0 Goals
Tomcat 5.0 looks great so far. It includes support for the Java Servlet 2.4 and the JSP 2.0 specifications, fixes many performance issues, and adds many new features and other improvements. Below we'll look at the two overall goals of Tomcat 5.0, which were implemented as of version 5.0.16.
Unifying the Two Tomcat Communities
An important goal for Tomcat 5 was to reunify the Tomcat communities under one codebase. A split had occurred in the Tomcat community between the Tomcat 3 branch proponents and the Tomcat Catalina developers. They each worked on their own branches and didn't collaborate much. Eventually, the Jakarta Project Management Committee made the decision that Tomcat Catalina was ready to replace Tomcat 3, and it was dubbed Tomcat 4. But because Tomcat 4 was a different implementation by a mostly different team of developers, migration from Tomcat 3 to Tomcat 4 was difficult.
Despite the committee's sanctioning of Tomcat 4, the community remained split, among developers and users alike. Each branch of Tomcat separately developed various features and performance enhancements. Several of these developments solved some deep problems in elegant ways, but depending on which Tomcat version a user used, only a portion of these solutions were available.
About the time that developers began working on Tomcat 4.1, both
Tomcat development teams agreed to work together on the Tomcat connectors, which included the
Java side of the JK2 connector, the HTTP connector (a pure-Java web server), as well as other
connector is a Tomcat core component that channels
servlet container requests into Tomcat.
The consolidation of the Tomcat 3 and Tomcat 4 connector code signaled a larger step toward reunification as it led to collaboration on other core performance issues, as well as development of independent servlet-container-version solutions, one of the last hurdles to unification. Tomcat 3 had been implemented as a small servlet container core that could be configured to load and use plug-ins called modules. Proponents of this design believe that keeping the core modular makes it both easier to maintain and more flexible. Tomcat 4's Catalina core was implemented modularly, but didn't offer the feature of generic servlet container modules.
Tomcat 5 includes Tomcat 4.1's core, and it adds the feature of version 3's generic servlet container modules. The developers still have some work to do in this area before it's clear what can and should be built as a module, and how it's generally done, but this work had led to the developer community working together again on all aspects of Tomcat.
Supporting the Java Servlet 2.4 and JSP 2.0 Specifications
The release of Tomcat 5 corresponds with the final release of the Servlet 2.4 and JSP 2.0 specifications, so now let's take a brief look at what's new in each spec, and what impact, if any, there will be on Tomcat 5 development.
The Java Servlet 2.4 Specification
The Servlet 2.4 Specification is only a slight evolution of the Servlet 2.3 Specification, so the API and semantics are almost completely backwards-compatible. With very few exceptions, Servlet 2.3 web applications should work fine in a Servlet 2.4 container.
This is great news for those currently using Tomcat 4 who wish to upgrade to
Tomcat 5 -- you probably don't need to modify your web applications. Keep in
mind, though, that your server.xml config file isn't part of your web
application; it's a Tomcat-specific file, and as such may need some
modifications to upgrade it for use with Tomcat 5. Since the syntax of Tomcat 4's
server.xml file is almost the same as that of Tomcat 5's server.xml file, this
shouldn't be difficult. I recommend that you start fresh with a Tomcat 5 server.xml file and migrate only the XML elements that you added to Tomcat 4's server.xml file. One way to see what you modified is to
your modified Tomcat 4 server.xml file against the untouched distribution version.
When you add those XML elements, look at the Tomcat
5 Configuration Reference pages and verify that each element's attribute
exists for Tomcat 5. This is especially important for the
<Context> elements, since they have each been modified in Tomcat 5.
The deepest impact that the Servlet 2.4 specification has on Tomcat 5 is the integration of XML Schema. In previous versions of the servlet specification, the deployment descriptors for servlet web applications were defined and validated using an XML DTD. This worked fine, but as it turned out, DTDs aren't quite modular or flexible enough for other technologies to be able to leverage servlet web apps as a framework. To achieve this level of flexibility and modularity, those involved in revising the Servlet 2.4 Specification and other J2EE 1.4 specifications decided to base the deployment descriptor definition and validation on the newer XML Schema, while maintaining backwards-compatibility with the older servlet 2.3 (and lower) DTDs.
The remaining changes to the Servlet API have been small, amounting to clarifications, bug fixes, and omission fixes. This is good news because it shows that the Servlet API is mature. Tomcat 5 fully implements all these new API changes and additions.
The JavaServer Pages 2.0 Specification
This new version of JSP is quite a bit larger due to its many new features, but aims to be backward-compatible with JSP 1.2. The most important addition to JSP 2.0 is the inclusion of the JavaServer Pages Expression Language (EL). Since EL is now part of the JSP container, EL became more useful because it can be used even in the middle of template text as opposed to just within certain custom tags. For Tomcat developers, the main thing to keep in mind with this new addition is that EL is now also part of Tomcat 5, which makes version 5 more featureful and easier to use than Tomcat 4 for developing detailed web applications.
Another new feature that JSP 2.0 includes is "tag files", which are JSP tags that are implemented as JSP fragment files and contain JSP content. Tag files make it easy to develop such things as modular page components, including XML content, which can be included in JSP pages. It's a feature, therefore, that's available only in Tomcat 5, offering web app developers something that Tomcat 4 does not offer.
Also included in JSP 2.0 are improvements to the handling of XML content, which allow developers to write their dynamic XML content as JSP content. The specification has numerous clarifications since version 1.2, and the file extensions .jspx and .tagx have been added. This feature isn't exclusive to Tomcat 5--other servlet container implementations are free to implement JSP 2.0--but this is a feature that Tomcat 4 does not have because it only implements JSP 1.2.
Tomcat 5.0 Features
Now it's time to get to Tomcat 5's major new features.
Performance Refactoring to Reduce Garbage Creation
The first enhancement to look at is Tomcat 5.0's memory-profiling tools. Tomcat 5 has been carefully optimized so that it produces less object garbage for the Java VM's garbage collector to have to clean up.
A typical problem with busy Java servers is that the server software constantly instantiates new objects, and when they're not needed anymore (typically, when a request ends), the objects are not reused but instead thrown out as garbage. The garbage collector must then find and reap all such objects to reclaim the memory they occupy. This takes time and CPU cycles to do, and in the meantime the whole JVM may be paused so that the garbage collector can finish its work. This means the requests currently in process must simply wait until the garbage collector is done, which makes the whole server slow down a little. Usually, this isn't a big problem because the garbage collector is pretty efficient at collecting garbage objects. But in some cases there is so much garbage being produced that it can't keep up, and eventually the amount of free memory gets low because there is a backlog of garbage objects using lots of memory. Or sometimes a web app creates very large objects that take the garbage collector longer to finalize and destroy, so the amount of free memory is lost in large chunks but isn't being replenished quite as fast.
Tomcat 5.0 has had many garbage creation (read performance enhancement)
changes since Tomcat 4.1. Tomcat 5.0's single most important garbage-creation
refactoring was the new request URI mapper. After some optimization profiling,
Tomcat 4.1's request pipeline was found to create excess garbage while mapping a
Connector's requests to the proper Container. For Tomcat 5, a whole new mapper
was implemented that generates little or no garbage (lots of object recycling is
going on in there), and thus Tomcat 5.0's request pipeline performs noticeably
better than that of Tomcat 4.1. This also lowers the overall memory usage compared to Tomcat 4.1, which helps to prevent
OutOfMemoryExceptions in the
web apps it runs, and helps Tomcat 5 to scale higher vertically (i.e. higher
scalability on a single machine).
Pages: 1, 2