Project: Convert current Tomcat valves to Servlet Filters.
Abstract: Apache Tomcat is an implementation of the Java Servlet and JavaServer Pages technologies. It is famous and widely used. It is also a component of an Application Server named JBoss Application Server. My task in this project is to convert current Tomcat valve based implementation into Servlet Filters which is consistent with the Servlet Specification.
Here is the roughly plan for this project:
Week 1: finish the very first valve - AccessLogValve, including testing and documentation work. The deliverables after this week are the source code of AccessLogFilter, including unit test code and documentation of this class.
Week 2: finish working with the ErrorReportValve and SSLValve
Week 3: finish working with StandardEngineValve, move its functionality into some "engine" level filter. And I also need to twist the "Engine", "Host", "Context" and "Wrapper" class a little to move on in this week.
Week 4: finish working with StandardHostValve, move its functionality into some "host" level filter.
Week 5: finish working with StandardContextValve, move its functionality into some "context" level filter.
Week 6: finish working with StandardWrapperValve, move its functionality into some "indivisual servlet" level filter.
Week 7 - 8: Do some integration test with current work to guarantee I do not break anything.
Week 9: finish working with RequestFilterValve and its 2 subclasses, refactor their functionality out into 3 corresponding filter classes.
Week 10 - 11: Refactor the functionality out of the AuthenticatorBase class and its subclasses into some structure which is consistent with the Servlet Container Profile in JSR-196.
Week 12: Integration test all the work. Check the missing documents and complete them.
Here I'd like to give some design option and my thinkings of this project. Thank you for your comment.
Since valves have different levels, such as server level, engine level, host level, context level. And there are several places for the configuration: server.xml, web.xml. For server level, both server.xml and web.xml is suitable, since both of them are some kind of global. For engine and host level, I think server.xml is much more suitable. And we could also use "$CATALINA_BASE/conf/[enginename]/engine-filters.default" for engine level filters, "$CATALINA_BASE/conf/[enginename]/[hostname]/host-filters.default" for host level filters and "$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default" for context levelfilters. This is the options for configuration file location that I could think about. In my opinion, we could put all these configuration in server.xml for simplicity, but keep an eye on those "$CATALINA_BASE/conf/[enginename]/[hostname]/" path just like tomcat deal with context.xml.default now.
2. Filters has orders, so the order they appear in the configuration file should be maintained. And some filter has to be the first one in the filter chain. I could not get an idea to guarantee this elegantly other than give some comment in the configuration file or in the documentation.
3. Do I need to remove all the pipeline facility or can I try to remove as much logic as possible from StandardEngineValve StandardHostValve/StandardHostValve? I found that those valve just delegate to the lower level pipeline(valves), and the lowest StandardWrapperValve will actually finish the job (filterChain and/or the servlet invocation).
All these jobs should be finished somewhere, if we do not use valves. Can I just override the invoke() method of Container interface for StandardEngine StandardHost/StandardContext/StandardWrapper, and high level container will call the invoke() method of the container which have a lower level than itself, for example, in invoke() method of StandardEngine, the invoke() method of StandardHost will be called. And I will move all the valve invoke() logic into the corresponding invoke() method of its container.
By the way, I'd like to added all the filters configurated in the server.xml file into the filterChain when the filterChain is created(in ApplicationFilterFactory.java line 143 or so, after "StandardContext context = (StandardContext) wrapper.getParent();") in the order of be configed in server.xml or some other configuration location. The general algorithm is like this: first, get to engine and host level through context (through getParent()); then add host and engine level filters into filter chain in the order of Engine -> Host -> Context. Is that a proper place for me to add those logic? What's the opinion of yours?