In practice, our implementation is much closer to Turbine 3 Pipelines than simple Servlet API Filters. This is possible by applying the same wrapping technology for FilterChain that is available for ServletRequest and ServletResponse (and which we also apply instead of a separate RunData object). That is, we wrap the incoming FilterChain implementation within the first Filter with our own implementation providing the additional features, such as grouping sets Filters to Pipes and branching between Pipes. Client objects, which need these features, have to do type casting, but most clients see the simpler and standardized FilterChain. By this way, we obtain the best from both solutions :-)
The main benefit is that we don't have to explain, justify and document for users yet another compilicated servlet request mechanism, but can simply refer to a standard API and all material already published around it. Advanced features are only extensions to the standard. In addition, Tammi can now be executed either as a standalone, as a servlet or as a filter chain. And Filters (Valves) can be configured with xml without specifying and programming an application specific schema and its parser ;-)
-- Ilkka
Daniel Rall wrote:
Ilkka, I'm curious about your thoughts on the Tomcat/Turbine pipeline
versus Servlet API FilterChains. My knowledge of Filters and
FilterChains indicates that they give only one direction of filtering,
whereas with the pipeline, you get another whack at filtering as
Valves pop off the stack. What is your evaluation of the flexibility
provided by the 3.0 pipeline versus the simplicity of the Servlet API?
-- To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org>
