Google Summer of Code 2009 Prposal


Convert current Tomcat valves to Servlet Filters


Buddhi Prabhath Wickramarathne



The Apache Software Foundation

Assigned Mentor

Mark Thomas

Project title

Convert current Tomcat valves to Servlet Filters


Apache Tomcat is a Servlet/JSP container. A Servlet/JSP container is a part of a Web server or application server that provides the network services over which requests and responses are sent.A servlet/JSP container also contains and manages servlets/JSP-pages through their lifecycle.

Valves are Tomcat specific components, which are used to manipulate the request/response process.Valves are provide functionalities such as accesslogging, authentication, errorreporting, requestdumping,requestfiltering etc. Valves can now(in current Tomcat version)be configured at three levels; the Engine level(valves can applied per engine), the Host level (valves can apply per host) and at the Context level(valves can apply per context) using Tomcat specific configuration facilities.Filters are the components that are specified in the Servlet spesification which are doing a similar work as Valves do.A filter can be defined as an object that performs filtering tasks on either the request to a resource (a servlet or static content), or on the response from a resource, or both.But unlike Valves, Filters can only cofigure per web application that means they cannot be configured at the Engine level,Host level; but only at the Context level.

This is the Project Proposal for converting Tomcat Valves to Filters, change internal Tomcat code using valves to use filters, enable the configuration of filters at Engine level and Host level, make sure that the new Filters are doing all the work what the old Valves have done. Update the documentation to reflect all changes.Valves are Tomcat specific but Filters can be used with any container so converted filters will be portable.After this conversion Tomcat's modularity and scope for re-use will be increased.


Here I have provided my proposed deliverables and timescale for delivering them. I have divided the time from May 23rd to 17th August mainly to 2 phases for delivering the completed work.

May 23rd - July 6th--First phase

Those Filters will be delivered in the first phase.

July 7th - July 12th

July 13th - August 10th--Second phase

August 11th - August 17th

Project Details

The major challenge of converting current Tomcat valves to Servlet Filters is enabling the configuration of the internal Tomcat filters at the engine and host levels -which are replacing the relevant valves-.

This is one place where I have to do some internal changes to the Tomcat.It'll not be very difficult task because the Web Context level configuration of the Filters are already implemented according to the servlet specification. So i have to go through those implementations and get to know them. But there will be new implementations to be done also.

1. Enable the configuration of the internal Tomcat filters at the engine and host levels - The filter requires a ServletContext at initialisation.

To Enable the configuration of the internal Tomcat filters at the engine and host levels, the Engine and the Hosts must have there own FilterChains. FilterChains and Filters can be created and cached using the factory for creation and caching of Filters and FilterChains which is ApplicationFilterFactory Filters perform filtering in the doFilter method. Every Filter has access to a FilterConfig object from which it can obtain its initialization parameters, a reference to the ServletContext which it can use.But at the Engine and Host level there is no Context. But there is a global web.xml that defines default values for all web applications which will be loaded into perticular instance of Tomcat.As each application is deployed, this file is processed, followed by the "/WEB-INF/web.xml" deployment descriptor from web applications. Here we don't have the 'no ServletContext' issue because we have Context per each web application at this level.

2. impact of servlet 3 and async processing

Since as described above "if" we choose to do the Valves to filter convertion according to above mentioned method the async process problem would not be arise. But it's not the case then this issue must be handled carefully. I have to think and search more about this issue have to find a different solution to this problem.

3. Authentication will require access to Tomcat internals - is a filter the right solution for these valves?

"If" we use the above described solution there will be a problem which is for Authentication. For the Authentication I would not suggest the above solution. So we must use an alternate solution.

"JSR196 says" This JSR define a standard interface by which authentication modules may be integrated with containers and such that these modules may establish the authentication identities used by containers.Providers integrated through this interface will be used to establish the authentication identities used in container access decisions, including those used by the container in invocations of components in other containers.The specification will define standard interfaces between containers and authentication modules to support the following interactions:

there are few interactions described

I have to study more about JSR 196 to make sure that (JSR implementations can be used to replace or not the Authentication Valves or there is another Valve replaceable solution for Authentication Valves.

Project Schedule

Proposed schedule in more detail


I am a third year student of Computer Science and Engineering Department of University of Moratuwa, SriLanka. I have been working with web server technologies for the last 6 months and I am familiar with Apache Tomcat. I am familiar with related APIs and specs such as servlet, jsp, j2ee etc. I also worked with spring mvc,struts.

During this summer I will only be having few other academic activities and a commitment such as 40 hrs a week average will be not be an issue.


buddhi (last edited 2009-09-20 23:36:27 by localhost)