Tomcat 7 Finalized 103
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."
Re:OK, I can't keep up (Score:5, Informative)
Tomcat is managed and run by the ASF, has nothing to do with Oracle.... not sure what you are going on about here.
Re:XML devils & details (Score:5, Informative)
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. ;-)