Google Summer of Code 2009 Prposal

Project title

Convert current Tomcat valves to Servlet Filters

Synopsis

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.

Deliverables

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

• Filters which can configure at the context level(global web.xml). (Some of the Valves can be replaced by the Filters which can configure at the context level)

Those Filters will be delivered in the first phase.

July 7th - July 12th

• Updates of the documentation to reflect the changes of Valves at the first phase(Work of Context level Filters).Sample test case deployment bundle.

July 13th - August 10th--Second phase

• Solutions for the Valves, that need a different solution which have to configure at the Engine and the Host levels will be delivered in the second phase.

August 11th - August 17th

• Updates of the documentation to reflect the changes of Valves at the second phase. Sample test case deployment bundle.

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 196-javax.security.auth.container) 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

• April 20 - May 3
  • This is the first 2 weeks of the community bonding period. I'll get to know more about mentors, community. Exchange ideas with them.Study thoroughly Tomcat internal Architecture about the Server,Service,Engine,Host,Connectors,Context standard implementations. Read more and familiarize with Servlet specifications(2.5,3),Jsp specification(2.1).I have already got the source code from the trunk and successfully built it.I am using eclipse and JIdea IDEs to edit the project and debug it. I have to configure JIdea to enable debug Tomcat.At this moment I can debug only using eclipse.Now I have some understanding and knowledge about how the server startup and the request process is happening in Tomcat.But have to study and make sure I understand every little detail of those processes.
  May 4 - May 23

  • In the second half of the community bonding period. As the community interaction and idea exchanging goes on I also read and understand the Valve source codes and there usabilities within Tomcat. As I know now there are Valves and there Bases such as AccessLogValve, AuthenticatorBase, CometConnectionManagerValve, ErrorReportValve, JDBCAccessLogValve, JvmRouteBinderValve, PersistentValve, RequestDumperValve, RequestFilterValve, SemaphoreValve, SingleSignOn, SSLValve, WebdavFixValve, JvmRouteBinderValve, ReplicationValve , BasicAuthenticator, ClusterSingleSignOn, CometConnectionManagerValve, DigestAuthenticator, ExtendedAccessLogValve, FastCommonAccessLogValve, FormAuthenticator, NonLoginAuthenticator, PersistentValve, RemoteAddrValve, RemoteHostValve, SSLAuthenticator, ValveBase.Discussing with the mentor and the community I have to figure out which solution is best for which Valve.Such as there is a problem using Filters with Authentication, the need of a Context problem, but at the engine and the host levels there is not one, like vice different Valves may need different solutions. So there is a need of recognizing Valve conversion methods to be optimized, make sure no duplication of code is happening, increasing the Tomcat's scope for reusability is accomplished by the proposed solution, no bug introduce is happening. So the First design phase of the Valve conversion is the most important part but as usually it may change later to another better solution. I have to do more experiments with Valves get to familiarize with them and to know the roles of each and every valve in detail.The role of the each Valve should be recognized and understand to provide same functionality using Filters.

  May 24 - June 14
  • Continuing the communication with mentor and the community, start to convert the easiest Valve to a Filter.Provide the same functionalities what the Valve does.Test the Filter, and remove bugs.This will be a Filter where I can configure it at the global web.xml file.Discuss with the mentor about this first converted Valve and get the feed back.Since the Tomcat internal code change is less in this conversion it will be less painful.Determine the other Valves must be converted to Filters at this level and start to convert them.There will be number of Valves I should work on in this level.Test them and debug them.
  June 15 - July 12
  • Continue the work with other Valves. According to the discussions if there is a design change work with those changes and do the conversions accordingly.Mid evaluations will begin and done during this period.
  July 13 - July 26
  • Continue with the conversion.The Valves that need a Different solutions will be consider most in this time.Discuss about those different conversions and use of different mechanisms.
  July 27 - August 9
  • Test the Filters one by one.There would be lots of testing scenarioes to be completed before replacing the Valves with new Filters.Clean the source code.Look for code optimizations to be done and do them.
  August 10 - August 17
  • Prepare the documentation. The documentation will reflect all the changes of the Tomcat.

Biography

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.

References

• Department of Computer Science and Engineering University of Moratuwa