tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Tomcat Wiki] Update of "SummerOfCode2009" by xxd82329
Date Wed, 19 Aug 2009 15:53:47 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:
http://wiki.apache.org/tomcat/SummerOfCode2009

------------------------------------------------------------------------------
  
  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. 
  
+ markt - Order should be:
+ (1) Global filters
+ (2) Engine filters
+ (3) Host filters
+ (4) Context filters
+ Where a filter is defined at multiple levels, merge the configurations using the Servlet
3.0 rules with the *lowest* level taking precedence (ie context > host > engine >
global).
+ 
  3. I will modify the digestor code in order to load the configuration about filters in,
ContextRuleSet.java, EngineRuleSet.java, HostRuleSet.java 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: 
  
  	private final FilterLevels level;
@@ -66, +73 @@

  
  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. 
  
+ For the discussing of configuration location of those converted filters, please refer to
http://wiki.apache.org/tomcat/SummerOfCode2009/LoadingFilterConfiguration. 
+ 
+ 
  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
   * Right now I don't know. I'd like to remove all the valve code if possible. It depends
how much access to Tomcat internals the filters end up needing. This question  probably needs
to be deferred until we have some working filters to make judgements based on.
  
- 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.
+ xxd - 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?
  
+ markt - The long term aim is to remove Valves entirely
+ 
  5. Valve interface has a event() method which is used to process a comet event. Filters
need not to worry about whether it is a comet event or not. So how can we reflect this part
in our new filter-based structure? 
  
+ markt - implements CometFilter interface to support comet based request.
+ 
  6. Do we really need to move the logic in StandardEngine/StandardHost/StandardContextValve
into some filters? Since the logic of these classes is purely servlet-engine concerned, I
do not think those logic could be reused by filters. Any comments? 
+ 
+ markt - Whilst removal is the aim, it may well end up making sense to keep some internal
Valves.
  
  7. My solution now to load configuration in $CATALINA_BASE/conf/server.xml is to add a CallMapParamRule.class
to collect the attribute-value pairs into a map, and this map is the initiation parameter
of a filter. A method with signature -- "addFilterWithConfig(Class<? extends Filter>
filterClass, Map<String, String> paramMap)" will be added in StandardEngine/Host/Context
to add new filters into it. The main content of CallMapParamRule is as blow: 
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message