tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Tomcat Wiki] Update of "SummerOfCode2009" by xxd82329
Date Tue, 16 Jun 2009 18:18:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The following page has been changed by xxd82329:

   * If yes, it just becomes a one-for-one replacement (all references to valves in code and
config changes to filters) once all the valves are available. In the meantime, filters can
be configured in contexts (per app or globally) for testing purposes.
   * If no, I'd be tempted to use web.xml to configure filters. There is already a global
web.xml. Adding the option of a per engine and per host web.xml should be doable.
+ xxd - How about the pipeline? If we remove those valves, this class needs not to be existed.
I found that this class is not widely used outside the hierarchy  of container interface.
And since these classes all implements Lifecycle interface, the start() and stop() method
will be invoked no matter whether these classes implement the Pipeline interface or not at
a glance. And the code in StandardPipeline are generally about manipulating valves, so if
we could remove all those valve structures, this class could be eliminated either. Any comments?

+  * and if we configure filters in web.xml, how do we differ engine and host level filters?
And context and wrapper (if exists) level filters of course should be configurated in the
corresponding web.xml, since it goes with the servlet specification. 
  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.

  markt - Filter order
   * This is already defined in the servlet spec. Look to see how Tomcat handles this currently.
+ xxd - I know the order of context level and wrapper level filters is already defined in
the servlet spec. What I mean is the filters of engine and host level. 
  3. I will modify the digestor code in order to load the configuration about filters in,,, in particular. And those filters
information will be store in an order map (I'd like to choose treeMap now) -- TreeMap<FilterMetaInfo,
Filter>. The FilterMetaInfo class is generally like this: 
@@ -59, +64 @@

   * This raises an interesting point. Is one single filter chain created in the same way
as it is now or do we create multiple filter chains - one per engine / host / context - much
like valves are now. Just because filters are defined at the engine level that doesn't necessarily
mean they have to execute there
   * Which raises the next question - which class loader loads the engine and host filters?
Single filter chain implies that the webapp must do the loading. That could limit what the
filter can do. Is that an issue?
+ xxd - I think all the filters need to be formed as a chain, and will be invoked when the
request comes in. Those engine and host level is just ordinary filters after they are added
into the filter chain. But before it, they have some global attributes compared with context
level filters. So, could we just add those engine and host level filters into the filter chain
when the filter chain is created? But for sake of performance, I think we could cache those
high level filters since they are global to some degree. 
  4. 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). 
  markt - See comment on point 3

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message