Announced this morning by the Apache Tomcat team:
The Apache Tomcat team announces that support for Apache Tomcat 5.5.x will end on 30 September 2012.
This means that after 30 September 2012:
Three months later (i.e. after 31 December 2012)
Note that all 5.5.x releases will always be available from the archive.
It is anticipated that the final 5.5.x release will be made shortly before 30 September 2012.
-- The Apache Tomcat Team
I’ve been sharing some thoughts about what’s become a significant trend in many IT organizations, and in particular with my clients…converting Java applications from JEE Application Servers to Tomcat, and more typically Tomcat+add-ons.
Many IT organizations are re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and the need to transition to more responsive/agile applications development. When IT organizations talk about “migrating” their applications, I’ve noted that they generally are focusing on one or more of three distinct situations. These are:
I’ve been focusing on the migration of existing JEE applications to the most popular of the light weight containers, Tomcat. There are many excellent reasons to consider moving applications off of the commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are focusing on the migration process, many of the business and technical decision factors apply equally well to the second and third situations.
This time, I will be discussing the technologies involved in migrating JEE application code from commercial JEE servers to Tomcat. I’d like to thank the kind (and very expert) folks at SpringSource, as well as a number of other friends around the industry, for their valuable insight regarding the technologies involved. Any errors (and opinions) are mine alone. Additionally, some of the material draws on information published by SpringSource and other open source materials found on the internet.
In a word, Yes. Tomcat is an "Application Server" for certain types of applications, including a large percentage of the applications being developed today. The answer depends, of course, on your definition of “Application Server”. It also depends on whether you think Tomcat is limited to the Apache Tomcat Project, or whether Tomcat also includes all the add-ons and plug-ins that have been made available through open source or commercially.
In any case, I assert that Tomcat is indeed an Application Server, all by itself. Tomcat becomes a much richer Application Server as you modularly (the only sane approach, IMHO) add functionality as required by your specific application.
I frequently hear the questions “What’s an application server?, “Is (or isn’t) XYZ an application server?”, and “Do I really need an application server?”. These questions also show up in various internet FAQ’s, blogs, etc. Some of the resulting discussions are almost hilarious, with firmly held beliefs sometimes swamping rational thought and one recent discussion at a major client bordered on open warfare. I too have some opinions, though perhaps not as vehemently held, based on years building applications across many architectures and technologies.
The short answer is that this is a myth. The longer answer is that back in the days of Tomcat 3 there was some truth to this depending on circumstances. However, for the versions of Tomcat in use today (5.5.x and 6.0.x) then there is no need to use httpd for purely performance reasons. Tomcat now supports the native/APR connector which uses the same native library (the Apache Portable Runtime—APR) as httpd for the low-level I/O and therefore can achieve similar performance to httpd. When serving static content there is ever so slightly more overhead when using Tomcat compared to httpd but the differences are so small they are unlikely to be noticeable in production systems.
If you research the httpd vs Tomcat performance issue, you will find a variety of load and performance benchmarks that show a range of results. An often quoted result shows that Tomcat's pure Java connector is consistently faster than httpd.
This particular result is the opposite of what is expected. httpd should be significantly faster than Tomcat's pure Java connector. This result is probably caused by the size of the file used. Tomcat caches small static files in memory by default and this will provide a significant performance improvement. httpd does not cache files in memory by default. This demonstrates quite nicely how the definition of the benchmark can have a significant impact on the results.
An approach to help correct this would be:
By default, Apache Tomcat dies its internal logging through juli. The quantity of information stored in the log files on any server can quickly grow to be quite large. For instance, the access log file typically grows 1 MB or more per 10,000 requests. Therefore, it may be necessary to periodically rotate the log files by moving the files or deleting the existing logs to free up space on the server and allow for more efficient searching through logs. This cannot be done while the server is running, because Apache Tomcat will continue writing to the old log file as long as it holds the file open.
For standard web applications, error messages and output are streamed to log files using sterr and stdout respectively. Some application developers prefer to aggregate all these messages into the application log.
The following steps are required to configure your web application's stderr and stdout messages be redirected to the application's log file for Tomcat 5.5 in ERS 3.1 utilizing java.util.logging:
Tomcat 5.5 documentation indicates that JAR files containing libraries should be stored in the webapps META-INF directory, per the JSP specification:
In Tomcat 4.1, the logVerbosityLevel attribute for the Logger element can be used to set the log level. FATAL, ERROR, WARNING, INFORMATION, and DEBUG are the valid values. The default setting is at the WARNING level.
In Tomcat 5.0, it can be changed through commons logging or log4j. Log4j is recommended as it has greater flexibility. In doing so: