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 :)

Have fun upgrading...

[MrEricSir]

...by editing thousands of lines of XML files by hand in various directories!

Re:Have fun upgrading...

[whiteboy86]

... a virtualization nightmare, definitely not recommended for production environments, needs lots of good (expensive) hardware to tame. Also, if you are running realtime OS on some low spec. board then the resource hoggishness and unpredictability is a major show stopper.

XML devils & details

[boorack]

I don't mind XML configuration file as long as it contains only things that are important and has little/no plumbing boilerplate. In most Java frameworks (especially in Spring) there are two things mixed into a single set of configuration files: items created once while developing application (for example Spring depencency injection bindings, Hibernate mappings etc. - let's call it plumbing) and factual configuration settings (for example: database URL, user and password for application). Mixing these two things is a major sin as plumbing and configuration have different characteristics.

Plumbing is like code. It is done while as part of application development and is tightly bound to development process - it should be easily testable, easy to refactor (IDEs should handle this - for example if you change name of some class/method, IDE refactoring features should also change it in all plumbing code). If possible - it should not change between development and production environments. That's why I prefer annotations rather than XML for binding everything into final application (eg. Guice over Spring). One notable exception I often is Hibernate and that's only because hibernate-annotations adds tons of additional JAR files and addidional complexity coming out of it doesn't justify convenience of using annotations instead of XML.

Configuration is a tool for administrators, not for developers. It should be as simple as possible and easy to change by hand. And yes, a generally prefer plain .properties files or YAML over XML, however as long as config file is simple enough and has no unnecessary overhead, I won't complain much about it. It is also important to keep major aspects of configuration separate (for example general server config vs. application specific config) and to keep application configuration separated from application itself (.war/.ear file).

So, in short: there are two things: "plumbing configuration" and real configuration. It is important to keep these two things separate and to keep real config as simple as possible.

Re:XML devils & details

[carpecerevisi]

In most Java frameworks (especially in Spring) there are two things mixed into a single set of configuration files: items created once while developing application (for example Spring depencency injection bindings, Hibernate mappings etc. - let's call it plumbing) and factual configuration settings (for example: database URL, user and password for application)

So pull them out into a .properties file and use a PropertyPlaceholderConfigurer to inject them into your XML file of bindings and mappings

That's why I prefer annotations rather than XML for binding everything into final application (eg. Guice over Spring)

Except Spring has annotation-based config and it's fairly nice?

(Disclaimer, haven't actually used Guice, but do spend quite a bit of time using Spring - your comments look as though they're based on opinions and experiences from using Spring version $old?)

Re:XML devils & details

[Temujin_12]

GP and parent both make good points. However, GP perspective is a bit outdated. Spring < 2.0 an earlier was all (mostly) about XML config. You'd have dozens and dozens of lines of XML to do what was ultimately a fairly simple task (ie: quartz jobs or AOP).

Spring 2.0+ (especially 3.0) made two very fundamental changes in "preferred" methods for application configuration. 1) XML namespaces and 2) increased use of annotations.

1) Going back to the AOP example, what used to take around 50-80 lines of XML in Spring < 2.0 and earlier can now be done in roughly 1/3 - 1/4 the config by using the <aop:...> <tx:...> or <scheduling:...> namespaces. You can still do things the old, verbose way, but now there's no reason to do so unless your either reinventing the wheel or have highly specialized needs that require low-level customization.

2) Spring has gone through their framework and found so-called "sweet spots" where XML-based config simply doesn't make sense. URL mapping, AOP pointcuts, autowiring or init methods, transactional behavior, all become much easier to configure as you no longer need swaths of XML to do something that a simple annotation can do (@Transactional anyone?). And inasmuch as there exists a standard Java annotation or JSR which specifies the same thing, they support that (following their "light weight framework" mantra).

A particular note on the parent's mention of PropertyPlaceholderConfigurer: I extended that configurer a couple years ago for our team such that it dynamically loads different sets of properties depending on the environment it is running on (defined by an environment variable). We pull nearly everything out into those properties files (app variables, logging config, profiling, etc) such that a single WAR file can be deployed on any of our environments w/o the need for any post-deploy reconfiguration.

As for DB config, that's the job of the servlet container. By using JNDI binding, there's no need for the application to worry about DB config at all (why would you want your production creds in a build anyways).

As for the web.xml in particular, most web.xml's I've seen for applications that are built by developers who understand the Spring framework (again > 2.0) are very thin. They pretty much just point to DispatcherServlet and URL config inside Spring (again minimized by using URL mapping annotations) take care of the rest. No need for servlet filters since Spring request interceptors do the same thing and in a much more flexible way. This is very much in-line with most frameworks which redirect all requests to a single entry point inside the framework (ie: wordpress, rails, cakephp, etc.).

Bottom line, be careful when you make/see the "Spring requires loads of XML config" argument. It usually comes from those whose idea of Spring is several years old.

And yes, I'm a Spring fanboy. ;-)

Re:OK, I can't keep up

[brunes69]

Tomcat is managed and run by the ASF, has nothing to do with Oracle.... not sure what you are going on about here.