You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2009/08/18 14:14:06 UTC
Re: GSoC2009 Project Wiki page updated
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSoC2009 Project Wiki page updated
Posted by Mark Thomas <ma...@apache.org>.
Xie Xiaodong wrote:
> Hello, Mark,
>
>
> I've made a separate wiki page for discussing the configuration location of
> those converted filters. And I updated the original wiki page based on your
> comments.
Thanks.
> By the way, I wish that I could propose a patch for web fragment
> implementation. Could you provide me more material other than the Servlet
> 3.0 specification?
That draft is all we have to work on. As it happens, I'm working on the
fragment implementation now. My plan is to commit as often as I can but
I'm nowhere near the point of having anything working just yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSoC2009 Project Wiki page updated
Posted by Xie Xiaodong <xx...@gmail.com>.
Hello, Mark,
I've made a separate wiki page for discussing the configuration location of
those converted filters. And I updated the original wiki page based on your
comments.
By the way, I wish that I could propose a patch for web fragment
implementation. Could you provide me more material other than the Servlet
3.0 specification?
2009/8/18 Mark Thomas <ma...@apache.org>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong