Xie Xiaodong wrote: > Hello, Dear All, > I have updated the GSoC2009 Project Wiki page. I've got some design > decisions to make, could you please spare me some time take a look at those? > Any comments are welcome. Thank you for your time.
The wiki pages are beginning to look quite crowded. Rather than add to that problem, I'll provide my comments here and let you update that page. 1. The main design decision as I understand it is how to handle filters at the Engine and Host level. Option 1: server.xml Outline: Provide support for a <Filter> element in server.xml to configure Engine, Host (& Context?) level filters. Pros: Similar to valves - can re-use most of the design Cons: Access to ServletContext Option 2: web.xml Outline: 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. Option 3: Do nothing Outline : Provides support for filters configured globally (CATALINA_BASE/conf/web.xml) or per context. Pros: No effort required Cons: Some filters (AccessLogs, RequestFilter etc) are typically configured at host/engine. Option 4: Something else? My preference is for option 2. I hope to start on the web fragment code shortly. Related questions (keeping numbering from wiki): 2. Ordering Order should be: - Global filters - Engine filters - Host filters - 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 think points 1. & 2. above cover this. 4. The long term aim is to remove Valves entirely. 5. This was addressed for the RequestFilter valves 6. See 4. Whilst removal is the aim, it may well end up making sense to keep some internal Valves. 7. & 8. See 1. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
