posted by Stacey Schneider on August 20, 2010 08:04 AM

In an email announcement today, the Apache Tomcat team announced the release of the Tomcat 7.0.2 beta.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.2 beta.

Apache Tomcat 7.0 includes new features over Apache Tomcat 6.0, including support for the new Servlet 3.0, JSP 2.2 and EL 2.2 specifications, web application memory leak detection and prevention, improved security for the Manager and Host Manager applications, Generic CSRF protection, support for including external content directly in a web application (aliases), re-factoring (connectors, life-cycle) and lots of internal code clean-up.

The 7.0.2 release contains numerous bug fixes and an important security fix compared to 7.0.0.

Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures.

Downloads: http://tomcat.apache.org/download-70.cgi

Migration guide from Apache Tomcat 5.5.x and 6.0.x: http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team

Read More

posted by MSacks on August 9, 2010 07:22 AM

With special thanks to Mark Thomas, ASF/VMware for reviewing.

Overview

This document will describe all of the necessary pre-requisites to get started in developing, customizing and contributing to the Apache Tomcat Project. The reader will have a broad overview of what is involved, and learn the process by which they will get a better understand of how the internals of how the Apache Tomcat application server works. Those new to the Apache Tomcat project, or contributing to an open source project may find this article helpful.

What is Apache Tomcat?

Apache Tomcat is the de-facto, open-source application server. It is distributed under the Apache License, Version 2.0 and is true open source. Many organizations use Tomcat as their production's application server, and it is enterprise grade even in its open source form. Over half of Fortune 500 companies use Apache Tomcat as their platform for their production business websites, including notables such as E-Trade.com, Walmart.com, and The Weather Channel. There are commercially supported versions of Apache Tomcat as well. In this how-to article, we will use the open source version as an example. 

Read More

posted by avanabs on August 2, 2010 07:57 AM

In my previous blog, I discussed the adoption of Tomcat 7 from the consultant/users view. I also promised an interview with one of the Apache Tomcat 7 committers, to provide the insiders views.

We’re here today with Mark Thomas, Apache Tomcat Committer and Release Manager for Tomcat 7.

Andy: Thanks for spending the time with me this evening. Congratulations to you and the Tomcat Community for achieving the Beta milestone for Release 7. We’re hearing interest from our clients, and it looks like there is lots of good stuff in this release.

 I understand that you are "Release Manager", as well as committer, for Tomcat 7...what does that role entail?

Mark: The Tomcat community has traditionally had a 'fixed' release manager for each major branch. It is fixed in that the same person does it for several releases in a row but in theory any committer could start a release at any point. As release manager, I build the release (do a clean checkout from svn and then 'ant release'), upload the release to a staging area and then call a vote on the dev list.

If the vote passes, I copy the files from the staging area to the distribution area, update the download links, update the latest version information on the Tomcat homepage, upload the maven artifacts and send out the release announcement to the lists. It sounds like a lot of work, but it is 99% automated.

Much more effort goes into the voting phase, where we check the release quality.

Read More

posted by avanabs on July 29, 2010 07:26 AM

I’ve been following Tomcat 7 development for some time now and I've been asked recently why (and when) clients should upgrade to Tomcat 7, now that it’s nearing release (currently targeted for “late summer”). So, I’ve started to give some thought to that question. I have to admit, the answer wasn’t immediately obvious either way. I’m going to split this blog into two parts; the first with my views and very preliminary results of my testing and evaluation. The second will be based on an interview scheduled for this Wednesday with one of the senior Apache Tomcat “committers”.

Note: In Apache Speak, a Committer is selected by his peers to be trusted to make changes to the code base. In a mature and extremely widely used project like Tomcat, this is very hard to achieve and carries great responsibility.

When I think about “upgrading”, I immediately think about two quite different scenarios.

1. Upgrading existing infrastructure for production environments. “If it works, why mess with it?” surely applies.
2. Selecting the infrastructure for new projects. “Should I really base my critical new project on a dot-zero infrastructure release?” is usually my first thought.

We’ll explore both situations, focusing on both Tomcat 7’s stability as a “dot-zero” release and what new capabilities Tomcat 7 brings to the table.

Read More

posted by jbrisbin on July 26, 2010 08:12 AM

You've spent a lot of time setting up a private cloud of servers. Everything's virtualized and you have it organized by function. Your messaging VMs run on these hosts and your web servers run on those hosts. You've tested it extensively and you're happy with how everything talks to each other. The worst is over, right? Wrong. Now you have to move past the theoretical and actually use this thing in production. It's time to start deploying the applications you're building into this cloud of virtualized resources. It's time to develop some scheme to keep your applications updated when changes are made. Keep in mind, whatever mistakes you inject at this point will be multiplied by the number of machines that deploys to.

Scared yet?

Don't be! It's really not that hard. In this article, I'll introduce you to some concepts I used in developing the fairly simple system of messages and scripts that deploy artifacts into our private cloud. This won't be a technical HOWTO so much as it will be a casual dinner conversation about the pitfalls and rewards. Above all, I want to get across that having a bunch of virtual machines that do the same thing doesn't have to keep you up at night.

Read More

posted by pledbrook on July 20, 2010 06:43 AM

Grails is a rapid application development framework for web applications on the Java platform. It's similar in many respects to Ruby on Rails, but it's based on Java libraries, like Spring and Hibernate, and the Groovy language. It also produces standard WAR files that can be deployed to a servlet container like Tomcat. That means you can deploy Grails applications to a Tomcat cluster and in this article I'll show you how.

Getting started

In order to demonstrate clustering, we need an application to deploy. Assuming that Grails is installed (I was using Grails 1.3.3 - the latest) we can create a brand new application with the command

grails create-app my-cluster-app

This will create a my-cluster-app directory containing the project. If we then switch to that directory, we can generate a WAR file straight away by running

grails war

Of course, the application doesn't do anything yet. Nor is it ready for clustering.

Read More

posted by jbrisbin on July 12, 2010 09:14 AM

It used to be common practice to "spare" the Tomcat server the drudgery of serving static content like images, CSS stylesheets, and JavaScript because it was faster to do that with Apache. That really hasn't been the case for quite a while now. With Tomcat adopting NIO and some of the really low-level performance improvements of sendfile and Asynchronous IO (AIO), it's not strictly necessary to have Apache in front of Tomcat any more.

We're probably like a lot of folks, though, and we have to have an Apache server somewhere to support the PHP applications we have (bad idea, long story). Since we already have an Apache server, we also use it to serve our static resources, just like everyone's been doing for years. We started with mod_jk because that was the only viable option at the time. When mod_proxy got AJP support, we switched to using Apache's mod_proxy and saw a nice performance boost. We stayed with this configuration for several years just because it's not terribly complicated and it just works.

But fronting Tomcat servers with Apache is pretty limiting when you start talking private cloud architectures. I discovered some big problems when I first fired up our SpringSource tcServer instances fronted by a couple of DNS round-robin load-balanced Apache servers. Tomcat was getting confused because requests were coming through different front-end proxies. I wrote my own session manager, which I discussed recently in two blog posts (<a data-cke-saved-href=" http:="" www.tomcatexpert.com="" blog="" 2010="" 06="" 21="" clustering-cloud-friendly-tomcat-sessions-rabbitmq-part-i"="">Part I & Part II), to get around this problem. But I still had the limitation of forcing users to go to an Apache server before being able to access the dynamic resources located in my tcServer backends. This created issues when I needed to take down the server Apache was running on.

Read More

posted by avanabs on July 7, 2010 05:42 AM

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:

• Moving existing applications (or slices of applications) off of JEE servers and onto lightweight, modular, horizontally scalable container infrastructures
• Expanding access to existing JEE applications by adding services layers in lightweight containers.
• Transitioning new development away from JEE application servers and focusing on light weight containers

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.

Read More

posted by jbrisbin on July 1, 2010 06:12 AM

In my first article on taking advantage of RabbitMQ's asynchronous messaging to implement a cloud-friendly session manager, I covered the method behind the madness and introduced you to some of the functions a session manager has to perform in the course of doing its job. In this, the second of two articles covering this topic, I'll describe how loading and updating session objects is handled and, in the interest of fairness, give some disclaimers and acknowledge the trade-offs made to get here.

The Code (at 1,000 feet) cont'd

Whenever code wants to interact with a user session, whether that be to load it into its own memory or to replicate attributes on that session, it sends these messages to a queue whose name contains the session ID. The pattern used to create the queue name is configurable so you can partition user sessions by application, or even by something more fine-grained (without resorting to using multiple, non-clustered RabbitMQ servers).

The session store first checks its internal Map to see if the requested session happens to be local to this store. If it is, the store simply hands that session back to the manager. If it's not, then the store sends a "load" message to the session's queue. It doesn't just fire off a message, though. It turns out that a user's session can be requested from the store many times during the course of a request. If one were to send a load message every time this happens, then we would see a serious performance degradation. To get around this, before a load message is sent, the store checks to see if it's already trying to load this session. If it is, it simply waits until that process is finished and uses the session being loaded in that other thread.

Read More

posted by mthomas on June 29, 2010 04:55 AM

A little under 18 months since work started on Tomcat 7 I am delighted to be able to say that the first Tomcat 7 release, Tomcat 7.0.0 beta, is now available from the Tomcat 7 download page at the Apache Software Foundation.

In addition to the implementation of the Servlet 3.0, JSP 2.2 and EL 2.2 specifications, Tomcat 7 boasts a number of new features. These include:

• memory leak prevention and detection
• protection against session fixation attacks
• a simple filter to add cross-site request forgery protection to an application
• simplified embedding
• alias support
• better security for the Manager and Host Manager applications
• and lots of internal code clean-up

Read More