Tomcat is the most widely used application deployment platform at AOL. As with most other web companies, we don't really need all the cruft, cost and complexity which "enterprise" application servers bring in. It is a tried and tested platform with good performance characteristics, easy administration and monitoring. It scales well enough. We run thousands of Tomcats serving hundreds of millions of pages. Since it is free, we don't need to scale by buying expensive servers, we can just scale out by adding more low cost servers (which, by the way, also adds redundancy)
I don't think Tomcat's goal should be to add features (read complexity) to compete with the so called enterprise application servers. It should continue to focus on being a performant Servlet/JSP container with easy development, administration and monitoring support. What I'd like to see added to Tomcat is:
- Easy ways to use Tomcat in an embedded fashion (like Jetty)
- Improve Tomcat manager
- Easy configuration for my webapp (Properties vs. JNDI/context)
Easy ways to use Tomcat in an embedded fashion
I don't see myself shipping a product with an embedded tomcat but I've frequently needed to have an embedded container for unit/integration testing REST APIs. Sometimes, I've used Jetty, other times I've mocked stuff. All of my production deployments use Tomcat so it is only natural that I use Tomcat for integration testing. Solr uses Jetty for testing and for providing a standalone example which works great. I like the easy embeddable nature of Jetty. However, I also believe that part of the reason behind the popularity of Jetty was that Tomcat was not embeddable enough. It had a lot of strongly coupled extra features (and a lot of related code) which were not needed. Valves, realms, JNDI contexts, authentication and clusters are things which are generally not needed in the embeddable scenarios. Note that embedding Tomcat is possible but it is not documented that well and there is no easy way to find out all the dependency jars I'd need to do that. The last time I did this successfully with Maven, I had to track down the dependencies myself and add each one to my application to make it work. So easy for me means: publish latest jars to Maven, use the dependency structure that Maven provides, make it easy for me to remove the extra features I don't need, focus on keeping the artifacts smaller and have good documentation on how to use the API.
Improve Tomcat Manager
A few months ago, I worked on a deployment application to push code updates to Tomcat servers across data centers. The use-case is simple. I want to update my application's code without causing a downtime. So I drain traffic away from individual servers, update the code, verify that it is in fact updated, and redirect traffic back to the server. I worked with the features provided by the Tomcat manager application. Not too many people actually use the Manager in the name of security but that's a separate topic. I wanted to add some custom commands to the manager and I couldn't because it was not designed to be extensible. In the end, I had to copy code from Tomcat's sources and modify to make it work. This is an area which could use some improvement. Coupled with good documentation on how to securely use the manager application, it has the potential to be used more widely. I want to use the Tomcat manager application from certain whitelisted IPs and only with SSL. Sounds simple but it was damn hard to get it working the way we wanted.
Easy configuration for my webapp
Configuration is a difficult issue. There are always so many right ways depending on who you ask. I just need to provide some key/value pairs to my application which change rarely but when they do, I'd really like them to be reloaded without bringing my application down. I'd really like to push those into the war but then I'd have different wars for different environments (dev/qa/prod) and that'd make some people very nervous (why?). I could use JNDI but that is much more complicated to manage than it needs to be for my simple use-case. Sysadmins don't like XML, and that is a well-known fact. It's easier for everybody to modify properties files vs an XML file for simple key/value pairs. I want to hot reload them, just like Tomcat hot-loads wars dropped into the webapps directory but I guess you can't do that. So I write my own small sweet library to read properties files from a certain location, checking every few minutes for changes to the file. If Tomcat itself had something similar, I'd just use that. I think it might be a very common use-case.
On a related note, I'm very excited about tomcat-lite, comet/bayuex and the new servlet API (asynchronous servlets) coming into Tomcat. I also wish for an easy way to write non-HTTP applications on top of Tomcat's NIO stack (again de-coupling may help) but that maybe asking too much. I know it's all do-o-cracy and I'm not doing my part. Someday I hope to contribute code rather than just ideas and complaints. For now, this is all I have.
5 comments:
Shalin, where did you run into this survey? I wonder if this is officially conducted by the Apache Tomcat team? Thanks!
I'm not sure if it was conducted by the Tomcat team. I found it as a sponsored link on gmail. The link pointed to tomcatsurvey.com which redirected to surveymonkey.com. It was a once only link so I can't access that page anymore.
A common solution to providing a single deployment that can work in multiple known environments is to change the JVM startup to specify a known system property, like "environment", with known values like "dev", "int", "uat", "prod", etcetera. Then, you simply package in WEB-INF/classes the following properties files: "env-dev.properties", "env-int.properties", "env-uat.properties", and perhaps "env-prod.properties" (some environments will require this file to be added by priviledged admins). You could also have this file referenced from outside of the container, using the CLASSPATH.
If it's not obvious, each properties file will define the same properties, with different values.
David, our operations group prefers having configuration outside of the war file. This way, they can make environment specific changes without having to modify the war cleared by QA, which is a huge relief to them.
In our current solution, we place these files outside and use a JVM property to point to their location, as you suggested.
Personally, I liked the profiles/filter approach taken by Maven. I tried to push for it but it didn't fly. The primary counter-argument was that the same bits which our QA group cleared are not installed into production. I don't really buy that too much. It's not like Maven will forget to include a file or two :)
As Berndf said, it's not a ASF Tomcat team survey, so it's *very* likely to be a marketing campaign, in order to get your email and send you consulting offers relative to tomcat.
Post a Comment