March 3, 2021
Hot Topics:

Top 7 Features in Tomcat 7: The New and the Improved

  • By Avneet Mangat
  • Send Email »
  • More Articles »

Tomcat 7 Enhancements: Evolutionary Changes

This section discusses the three previously identified enhancements.

5. Servlet 3.0, JSP 2.2 and JSP-EL 2.2 Support

The enhancements in Servlet 3.0 are:

  • Ability to use POJOs as servlets and/or filters using annotations (web.xml is not required)
  • Ability to describe deployment in Web fragments -- Web fragments are XML files with only partial deployment information. The servlet engine composes the final web.xml from these Web fragments. This is expected to reduce complexity in web.xml files.
    As an example, struts.jar and spring-mvc.jar could each have a web-fragment.xml.The developer will not have to configure struts/spring-mvc in the web.xml. The web-fragment.xml in the JAR files will be automatically detected and the struts/spring-mvc servlets and filters will be auto-configured.
  • Async processing of Web requests -- This feature was available in Tomcat 6 but it has now been standardized in Servlet 3/Tomcat 7, making Web applications that use async I/O portable across Web containers. This uses non-blocking I/O, and every HTTP connection doesn't require a thread. Fewer threads can serve more HTTP connections. This is particularly beneficial where the HTTP request triggers a long-running process and then returns a result (e.g. report generation, slow databases, Web service calls).
  • Security-related changes -- Servlet 3.0-compliant containers can now use SSL for session tracking instead of cookies and URL rewriting.

DevX published an excellent explanation of Servlet 3.0 changes.

6. Easier to Embed Tomcat in Your Applications

Tomcat can be embedded in an application and it can be configured and started programmatically. Most of the configuration in CATALINA_HOME/conf/server.xml has to be done programmatically. Prior to Tomcat 7, Tomcat 6 provided an Embedded class, which had convenience methods to configure Tomcat. This class has been deprecated. The new class Tomcat uses defaults for several config elements and provides an easier and simpler way to embed Tomcat.

Here is the general structure of Tomcat configuration elements from CATALINA_HOME/conf/server.xml and some relevant attributes:

< Server > < Service > < Connector port="8080 > < Engine > < Host appBase="/home/avneet/work/tomcat7demo/dist" / > < /Engine > < /Connector > < /Service >< /Server >

To configure these programmatically, you have to build all the objects above and configure them. Here is the Java code to do this:

final String CATALINA_HOME = "/home/avneet/work/temp/tomcat7demo/"; Tomcat tomcat = new Tomcat(); tomcat.setBaseDir( CATALINA_HOME ); tomcat.setPort( 8080 ); tomcat.addWebapp("/tomcat7demo", CATALINA_HOME + "/webapps/tomcat7demo.war");

tomcat.start(); System.out.println("Started tomcat"); tomcat.getServer().await(); //Keeps Tomcat running until it is shut down //Webapp tomcat7demo accessible at http://localhost:8080/tomcat7demo/

7. Asynchronous Logging

Tomcat 7 now includes an asynchronous file logger (AsyncFileHandler). AsyncFileHandler extends FileHandler and can be used in place of FileHandler. To use AsyncFileHandler, simply replace all occurrences of FileHandler with AsyncFileHandler in the CATALINA_HOME/conf/logging.properties file. The application must use java.util.Logging; asynchronous logging does not work with Log4j.

When a log message is sent to the AsyncFileHandler, the log message is added to a queue(java.util.concurrent.LinkedBlockingDeque) and the method invocation to log a message returns immediately without waiting for the I/O to disc. A separate thread is started when the AsyncFileHandler is loaded by the class loader. This thread reads log messages from the queue and writes them to the disc.

The advantage of this approach is that if the I/O to disc is slow (e.g. log files on a remote drive), logging will not slow request processing.

AsyncFileHandler employs a producer/consumer relationship with the queue to store log messages. The default queue size is 10000. In case of overflow, the default behavior is to drop the last message. Both the default size and overflow behavior can be configured using startup system properties.

About the Tomcat 7 Demo Application

The attached Tomcat 7 Demo Web application has two servlets. One servlet is demonstrates how to use a nonce to prevent CSRF, and the second illustrates the use of aliases. Update the web/META-INF/context.xml file to point to the absolute folder where the images are (e.g. ./images).

Build the war file using build.xml and deploy it in Tomcat 7. Use the two URLs below to see CSRF filtering and aliases in action:

  • http://localhost:8080/tomcat7demo/csrf/
  • http://localhost:8080/tomcat7demo/alias/


The Tomcat team introduced several changes in Tomcat 7 in terms of both new features and enhancements to existing features. The changes had not been tested in production systems at time of writing (the latest stable release was 7.0.2), but in 6-12 months they will be mainstream and make it easier for developers to deploy more secure, high-quality Java-based Web applications.

About the Author

Avneet Mangat has 9 years of experience in Java/J2EE development and currently works as an independent IT consultant in London. He holds a master's degree in software engineering from University of Oxford, and is a Sun-Certified Java Programmer, Web Component Developer and Enterprise Architect, an Adobe-certified Flash Designer, and is Prince2 certified (foundation). He is the lead developer of the open source tool DBBrowser.

Page 2 of 2

This article was originally published on September 22, 2010

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date