Tomcat 7 Finalized

alphadogg writes "The volunteer developers behind Apache Tomcat have released version 7.0.6 of the open-source Java servlet container. 'This is the first stable release of the Tomcat 7 branch,' developer Mark Thomas wrote in an e-mail announcing the release on various Tomcat developer mailing lists. While not a full application server, Tomcat implements the functionality described in the Java Enterprise Edition Web profile specifications. Most notably, it supports version 3.0 of the Servlet API (application programming interface) and version 2.2 of JavaServer Pages, both part of the recently ratified JEE 6. A servlet container manages Java-based applications that can be accessed from a Web browser. One big area of improvement is in configuration management for Web applications. Previous versions required all Web app configuration changes to be entered in a central file called web.xml, a process that led to unwieldy web.xml files as well as security risks."

Comments

Web.xml is the reason I hate Spring

[euroq]

Large centralized files suck. At least they do when you have to deal with a real website with real, complex functionality.

Tomcat is as rock solid as it gets

[BeforeCoffee]

Tomcat 6 has been a rock solid server for me for years. It's fast, it's easy to roll out, it can scale, and it's real tough to break. (Has it been cracked in the wild?) The non-blocking I/O extensions to the servlet spec were genius, and I wish other vendors had picked that feature up.

I look forward to much more goodness with Tomcat 7, sounds like there are tons of refinements to security and the codebase.

Thank you Apache and thank you Tomcat team!

Re:Tomcat is as rock solid as it gets

[whizzter]

It's solid for normal serving of servlet stuff but that's about it sadly.

- Your "security record" comes from the fact that tomcat is written in a "safe" language, a security hole would have to come from some stupid manual hole, a JVM bug or the APR connector.

- The non-blocking extensions are non-standard, and much worse than that is that those extensions only works with the APR connector (IE NATIVE C CODE!) but are only experimental with the portable NIO connector (after alot of debugging my own code i finally found a blog post about NIO not working with tomcat async). So it means that you need to be compiling/installing the tomcat code for the target platform before deployment instead of just copying over the JAR's or something like that as you'd be expecting with a Java app.

- The internals are quite contrived, oh i'm sure there's a good reason and prolly has to do with the APR/NIO/"classic" multi-connector support but it made me drop the option of actually fixing the NIO support. (so the open source advantage goes out the door)

- Last i tried (autnum) the API for servlet 3 async was there in tomcat7 but it seems the implementation wasn't? gave me alot of headache and the APR only support for their propeitary async api finally broke most of my faith in tomcat as a future platform.

The most ironic part about all of this is that i decided to do a quick project with a "established" base system and not be hacking things up, but i'd say i rediscovered a truth. If you want to do something new with an established package you might just run into experimental features and/or features that would requie the entire system to be rearchitectured (both in the case of tomcat).

I've now taken a big leap to an "experimental" platform(Node.JS) and while not perfect at all it was built from day one for the kind of things i wanted to do. Oh and working with Javascript on a small project is an absolute pleasure compared to Java :)