The most prominent change is the support of Servlet 3.0 specification which supports such great features as
- asynchronous servlets – not used by default
- web-fragment.xml - you can specify parts of the configuration in your libraries which you plan to reuse
The effective deployment descriptor (web.xml) now is the sum total of all the fragment configurations contained in the application’s libraries. This means that you need to be more careful when using 3rd party libraries because they can contain some configuration portion that will prevent your application from working like you expected. But to my understanding you can fixate the effective web.xml used and prevent tomcat from scanning all the libraries for configuration fragments. Now deployment descriptors support programmatic configuration i.e. you can decide how to configure an application at startup by considering the environment the server is in and other variables.
Another interesting thing to note is that before the Servlet 3.0 specification implementation tomcat used two methods of session tracking: cookies and rewriting the URL with the JSESSIONID parameter. The latter in tomcat was mandatory meaning you could not easily switch it off. I actually tried some workarounds, but they produced some side-effects. If anyone knows a proper method to avoid ever seeing the JSESSIONID parameter in Tomcat 6 please let me know. In Tomcat 7 the URL rewriting method is no longer mandatory and a new session tracking method was added based on SSL session. It is more secure, but I believe it needs two-way SSL configured. Don’t quote me on this, because I might be wrong about the two-way SSL, will have to check it. While we’re at it I can mention that now there’s the ability to change the session cookie’s default name, domain and path.
Not much to talk about other than saying that Tomcat 7 supports it. And maybe worth mentioning that you can now specify the defaults for the content type you’re returning and the buffer size. Also there’s a nice configuration option added called error-on-undeclared-namespace which quoting the documentation does the following:
The default behavior when a tag with unknown namespace is used in a JSP page (regular syntax) is to silently ignore it. If set to true, then an error must be raised during the translation time when an undeclared tag is used in a JSP page. Disabled (false) by default.
And here’s an example of how you would use this option
Also note that Tomcat 7 implements EL 2.2 and now is much stricter about the EL specifications, but according to Mark it’s unlikely to affect many users unless of course you’re doing some kind of hack with it.
Memory leak protection
This is a nice new feature in Tomcat 7 which has been backported to Tomcat 6 and if you’re using version 6.0.24 or later, you can enjoy the benefits. It’s implemented as a listener which tries to detect and fix the possible memory leaks whenever it can. These are the leak cases that it tries to prevent:
- JDBC drivers – they should be de-registered upon application stop
- ThreadLocals – if you create it when processing the request, you must set it to null before completing the response
- Threads – if a webapp starts a thread (e.g. scheduler) it must stop it, Tomcat doesn’t do that for you because it might crash the JVM, but it does report the problem in the log files
- ResouceBundle – Tomcat automatically fixes this one, but if you want some details turn on debug logging
This is said to be a much requested feature which allows you to map a .war file or a directory with static content that you could for example share among other applications deployed on that server. The main advantage over using symlinks is that when using a symlink Tomcat follows it and undeploys the content along with the application. This is done by specifying the attribute alias in the <context> tag that looks something like this alias=”/aliasPath=docBase” and remember to use the absolute path when specifying the content location.
Even more changes
There are more changes like the ones in the manager application or the jdbc-pool library, but I won’t try to review them here. Other ones include embedding improvements which allow you to easily embed Tomcat using the class org.apache.catalina.startup.Tomcat and then do programmatic configuration of the server. This seems extremely useful for things like integration tests and in fact most of Tomcat 7 unit tests use embeded Tomcat. Tomcat 7 prevents session fixation attacks by default by changing session ID on authentication. Internal changes include switching from Valves to Filters. This change is ongoing and should eventually replace all Valves. And one thing you might notice when running the new Tomcat is that access log valve is enabled by default. This means that you’ll get another file in your logs directory which will log all access to Tomcat server. It’s formatted just like the Apache HTTP server’s access log and is useful in a number of situations.
I am using Tomcat 6 and 7 side by side for my current needs and can say that Tomcat 7 with all it’s nice features does contain a few bugs so don’t rush into using it for any environments that need stability. I’m still playing with the new Tomcat’s features and maybe will write another post regarding that.
Since this post is still relevant and gets a reasonable amount of traffic I decided to update it by putting a link to Mark Thomas’s recent presentation on What’s New in Tomcat 7, so that you would get the information straight from the source. The sound quality isn’t that great, but it’s worth watching/listening if you’re interested and have a half an hour to spare.