Slashdot Mirror
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."
Large centralized files suck. At least they do when you have to deal with a real website with real, complex functionality.
Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
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!
Your post, while well-written and pleasant, did not include the word "suck".
...by editing thousands of lines of XML files by hand in various directories!
There's no -1 for "I don't get it."
Nice to see, that the acronym API was explained, but words like "servlet", "branch", "application server", "javaserver pages" were assumed to be understood by the reader.
Person who does understand those, maybe knows what API stands for in this context.
Oracle is evil, and I'm not going with anything that they've got or derived from anything they've got in a way that they can control, no matter where it came from. I don't care if it's Sun-based or whatever. If it's got the Oracle taint on it I ain't interested. A fork that ain't beholden to them might be interesting.
So where are we at with this?
Help stamp out iliturcy.
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.
Just wanted to share my experience of building a real production product based on Tomcat 7. We've been using it for the past 8 months, ever since the release candidate, and specifically wanted to exploit the async servlets of Servlet 3.0 spec. Jetty didn't fit what we needed, so Continuations was out.
Why did I post the background? Read this: http://www.tomcatexpert.com/blog/2011/01/11/field-report-tomcat-7-action. It's just a play-toy for articles like that, but real production use of Tomcat's asynchrony is hard and I've spent weeks trying to track down strange race conditions occurring because of that. I had dreams where I saw NullPointerExceptions at times. Maybe I'm just a bad programmer, or maybe weird shit happens with asynchrony. So be cautious before you gleefully jump into the puddle. The problems with Asynchrony nearly cost us our planned release date. It did, however, cost countless weekends and nights of mine.
That said, the development of TC 7 has been really very rapid. There was a complete rewrite of how Asynchrony works from Tomcat 7.0.2 to 7.0.3. Not something usual for a minor version change. The server itself is fast and really stable (except for a bad memory leak they fixed in 7.0.3. That cost me four days trying to find the leak when I was with 7.0.2, before checking out the TC commit logs).
The annotations support in Servlet 3.0 makes life WAY easier, no messing around with web.xml and stuff anymore to configure servlets.
So my experience has been a mixed one. It probably will get better for new folks who're using TC 7 stable; a known tradeoff for using unstable beta server is that it's unstable :-) There have, however, been no problems whatsoever with using 7.0.5. So go ahead, try it out!
I'm stuck developing and deploying apps to JBoss 4.0.5.GA . I have problems when I deploy a WAR file that contains struts jars and other jars that conflict with the jars already installed in the JBoss. Is there a chart of feature comparisons between all the version of JBoss (and the underlying Tomcat) that could show which version has features to help me avoid those problems? FWIW, I use Eclipse Helios for development and testing, while another group runs ant against a build.xml I supply to deploy (and I'd like Eclipse to automatically generate and maintain the build.xml ).
--
make install -not war
I for one welcome our non-crashing on redeploy overlord. Lots of memory leaks due to deploying and removing individual webapps are now fixed.
I work in IT, but my heart is in 1980s Japanese pop music. Whenever I use Tomcat, I think of this.
Sendou Wave Kick!!
Basically how can execution of a thread be stopped [...]?
The short answer is that a thread can never be both arbitrarily and safely stopped. That's why Thread.stop() has been deprecated since nearly its introduction in Java. There's an official summary of the reasons, linked from the API. Essentially any forcible stoppage of a thread could silently compromise the thread-safety of the entire application.
How do you even time out Executor threads after a fixed amount of time?
If your worker threads happen to by blocked on IO or something similar, or they are waiting for a synchronization monitor, then you can indeed interrupt them. However, that doesn't seem to be the case in your situation; you seem to be saying that these threads aren't waiting, they're just merrily running along, doing productive work. You want them to be arbitrarily halted after some time or some event, but that's just not possible.
In those cases, your threads are supposed to police themselves, usually by polling some external signal (set by another thread) indicating that they should give up. Since threads can't kill other threads safely, the very mechanism has been deprecated. By the way, this has nothing to do with the (relatively new) Executor threads, nor with any particular version of Tomcat.
Fucking pussies whining about large XML files. You can save thousands, if not 10s of thousands of lines of code, by using dependency injection, and code reuse through pluggable interfaces with filter chains.