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 Mon, 15 Jun 2009 09:36:13 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

------------------------------------------------------------------------------
  
  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. 
+ 
+ 1. 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?
+ 

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


Mime
View raw message