Coffea Works

Dallying with Tomcat 5.5

Q and A with Yoav Shapira

by Dilip Thomas

Following extensive redesign and refactoring, the Tomcat team recently announced the first release of the new Tomcat 5.5 branch, Apache Jakarta Tomcat 5.5.0. This release sports increased performance and an improved internal structure. Although not a stable release, it sets the tone right for a solid 5.5 release, replete with significant additions, a possible change in packaging, dependencies, and Tomcat internal APIs.

Within a week following the release of 5.5, the second build of the 5.5 branch hit the road. As the excitement towards a rock stable Tomcat 5.5 release builds up, we got Dilip Thomas to buzz one of the committers of Tomcat, Yoav Shapira, to help demystify the new features. Here we present Yoav's responses to the top questions that he posed:

Q #1. The release announcement of Tomcat 5.5 noted that it was a not-so-stable release. Has the second build of this branch, Tomcat 5.5.1, addressed these stability issues?
To some extent. We've yet to test it extensively. The branch should be regarded as unstable until the first 5.5 stable release is announced. Judging from history it takes several builds, not just one or two, before this happens.

Q #2. How would you compare Sun's JDK with Eclipse's JDT? What advantages can the Tomcat user derive by using the new Eclipse JDT Java compiler bundled with Tomcat 5.5?
The main reason for the change was to not require the JDK. By having Tomcat require only the JRE instead of the JDK, we make it much easier for users/resellers/integrators to bundle Tomcat or redistribute it without the license concerns raised by requiring the JDK.

Q #3. Are there any other reasons, outside of license concerns, that paved the way for the new Eclipse JDT Java compiler in Tomcat 5.5? For example, performance considerations?
The licensing difference was our primary reason for changing to the new compiler. We are still exploring its features and may expose more of them in the next builds of Tomcat 5.5. A nice side benefit of this change is that it's now very easy to switch between the JDT and Ant compilers, or plug-in your code class that implements the one abstract method in the org.apache.jasper.compiler.Compiler class.

Q #4. What effect, in terms of stability, does the dependency on JRE 5.0 pose, given that JRE 5.0 is still unstable?
It means we can't officially announce a stable Tomcat 5.5 release until the JRE 5.0 FCS is out. However, we're not too concerned, as numerous users as well as Tomcat developers have been running Tomcat 5.0.x on the JDK 5.0 betas for months now without significant problems.

Q #5. Tomcat 5.5 is built to leverage on J2SE 5.0s built-in JMX capabilities. Typically, in what scenarios would this benefit a Tomcat user?
It benefits us, the Tomcat developers, in that we can make more container attributes and methods available via JMX while at the same time reducing the complexity of the JMX-related code. It benefits users in that we expect the JMX features included in J2SE 5.0 to become widely used and adapted, and therefore more familiar to users wishing to integrate Tomcat and control it via JMX in their own products. This should also make it easier for console products like MC4J to integrate with Tomcat.

Q #6. Can you comment a bit on the usage of commons-logging, and how it improves overall exception handling?
We've been on a trend of using commons-logging more, and Tomcat's proprietary Logger interface less, for more than a year now. That trend culminates in Tomcat 5.5 with the removal of the Logger interface. There are enough good logging interfaces, toolkits, and implementations out there that we don't need to implement one, on our own. Now that commons-logging has achieved a significant hold on the market, and our users are familiar with it as shown in our mailing lists, we wanted to make the configuration of Tomcat's logging easier for them and for us. It's one more pseudo-standardized part of Tomcat and one less proprietary part -- always a good thing.

Q #7. So, what other parts of Tomcat are still proprietary, and what are the chances that we will see more of these phased out in future releases?
We'd like to strike a good balance between using standard interface (J2SE, J2EE, Servlet Spec, etc.) and allowing our users to easily customize and enhance Tomcat. Some interesting candidates for deprecation or replacement are the org.apache.catalina.Valve interface (which was designed before Servlet Filters were available), and the JNDI-related interfaces (org.apache.catalina.Resources). In fact, there has been talk in the past about breaking out Tomcat's JNDI-related code into its Jakarta JNDI Server project, but I'm not sure what became of that. This is similar to what happened with Jakarta Commons Daemon and Jakarta Commons Modeler, which used to be inside Tomcat and specific to Tomcat.

Q #8. The server startup performance of Tomcat 5.5 has been extensively profiled and optimized. Can you comment a bit on the performance aspect? Are there any benchmarks that you can point us to?
We were mildly but pleasantly surprised to see that for many cases, user web application startup time dwarfs Tomcat's own internal startup time. It is fairly common for user web applications to do costly operations, such as creating connection pools or pre-caching some data, during webapp initialization. Sometimes these are better done on-demand, but of course that's an application-specific design consideration.

We didn't find much to improve in the startup time profile. We did apply common performance tuning techniques, like reducing the calling stack size and removing unused method parameters.

Publicly published benchmarks are not yet available. We might provide those at 5.5 stabilizes, but in the past we preferred benchmarks to come from independent parties or organizations. There is always enough debate considering the validity of benchmarks without the conflict of interest issue of publishing your own benchmarks of your own product.

Q #9. It may be early days to even think about Tomcat 6, but how do you see the roadmap for Tomcat'shaping in the releases to come?
We plan to continue the major version-numbering scheme that we have used in the past, so Tomcat 6 will be available when the Servlet Specification version 2.5 is finalized. In fact, what features and changes will go into Tomcat 6 is largely dictated by changes to the Servlet Specification.

Beyond that, we will continue with the current approach: security and showstopper bugs are addressed immediately by everyone available to help, and after that every developer works enhancing and fixing bugs in his or her own area of interest. We have a great team with diverse interests, so this approach has worked well for years, and we feel no need to change it ;)

I personally am interested in improving the Tomcat documentation, as well as its meta-documentation: links and cross-references to external tutorials, forums, demos, and books. I think as the Servlet technologies and Tomcat themselves mature, there will be less exciting new core features. Instead, I'd like to improve issues around the core product: documentation as I said above, packaging, performance, and usability.

Of course, we always encourage users to let us know what they think, and suggest improvements, on our mailing list: http://jakarta.apache.org/site/mail2.html#Tomcat.

Closing Notes
Thanks for reading! We hope this Q&A has helped demystify some of Tomcat 5.5's new features and related issues. If you'd like to see a Q&A on any of your favorite JAX technologies, write in to editors@jaxmagazine.com with your topic suggestions and any burning questions that you'd like to see, answered by authorities in the community.
Yoav Shapira works for Millennium Pharmaceuticals and is as interested in the business aspects of Open Source Software as he is in the technical aspects. Yoav contributes to the Tomcat container, the Log4j logging system, and a number of Jakarta Commons and other Open Source projects.
Dilip Thomas is an Open Source enthusiast who keeps a close watch on LAMP technologies and the full range of Apache Jakarta projects. He is co-author of Apress's PHP MySQL Website Programming (PDS) and a technical reviewer on several Open Source/Open Standards book projects. Reach him via e-mail dilip[dot]thomas[at]gmail[dot]com.

References