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 markt
Date Mon, 15 Jun 2009 20:35: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 markt:
http://wiki.apache.org/tomcat/SummerOfCode2009

The comment on the change is:
Add some comments

------------------------------------------------------------------------------
  
  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. 
+ 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.
+ 
+ markt - Are Valves going to be removed completely?
+  * 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.
  
  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.
  
  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: 
  
@@ -48, +55 @@

  
  FilterLevels is an enum which contains: ENGINE, HOST, CONTEXT. 
  
+ markt - Point of execution
+  * 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?
+ 
  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.
  

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


Mime
View raw message