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/LoadingFilterConfiguration" by xxd82329
Date Wed, 19 Aug 2009 16:10:41 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/LoadingFilterConfiguration

------------------------------------------------------------------------------
   
  1: we could add those configurations into conf/server.xml
  
- pros: the place for configuration keeps consistent with that of valves. And we could also
use similar syntax as valves. So I think this is least abrupt way for configurating filters.
+ pros: the place for configuration keeps consistent with that of valves. And we could also
use similar syntax as valves, such as <Filter> element. So I think this is least abrupt
way for configurating filters.
  
- cons: Maybe a little strange to config somewhat general Servlet structure into a tomcat
specific configuration file. And need some hacking for squeezing those configurated filters
into filter chain.
+ cons: Maybe a little strange to config somewhat general Servlet structure into a tomcat
specific configuration file. And need some hacking for squeezing those configurated filters
into filter chain. And it is difficult to access ServletContext. 
  
  2: we could also support "$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 just as tomcat do now for "context.xml.default"
  
- pros: keep consistent with valves. And somewhat the same as the first method. I think this
could be the complement of the first one. 
+ pros: keep consistent with valves. And somewhat the same as the first method. I think this
could be the complement of the first option. 
- 
+  
- cons: But I think this way is more verbose than the first, since configuration scattered
into several places. Considering the situation of valves, there are not too many filters need
to be configurated in this way.
+ cons: But I think this way is more verbose than the first, since configuration scattered
into several places. Considering the situation of valves, there are not too many filters need
to be configurated in this way. And other defect of this option is just the same as option
1.
  
  
  3: Put all those converted filters into the global conf/web.xml, and using some extra parameters
to determine the level(server/engine/host/context) which this filter belongs to. 
@@ -26, +26 @@

  cons: the global conf/web.xml file is rather long now. Scrolling this file and adding or
altering it could become a burden to developer to some degree. And I think those additional
parameters harms the portability to some degree. 
  
  
+ 4: Raised by Mark. Provide support for a host and engine level web.xml files
+ Pros: Simple to implement,particularly with Servlet 3.0 requirements for web fragments.
Should be very easy to extend.
+ 
+ Cons: One instance of filter created per context, even when filter is defined at host/engine.
Would require more objects.
+ 
+ 
+ 5: Something else?
  
  
  Are there any other places or methods that could put the configurations for those converted
filters? Any comments are welcomed. Thank you for your time. 
  
+ 
+ (Mark prefer option 4. And he hopes to start on the web fragment code shortly. )
+ 

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


Mime
View raw message