Is a "filter chain" just:
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/FilterChain.html
? Or is this another abstraction on top of the servlet spec?
--------------------------------------------------
From: "Wes Wannemacher" <[EMAIL PROTECTED]>
Sent: Saturday, June 21, 2008 1:30 PM
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [s2] New filter strategy RFC
I'm all for cleaning up the filter dispatcher. One thing I came across
while working on a project recently is the Spring idea of a filter chain
(necessary when using ACEGI). I don't want to make Spring a dependency
on core, but the idea of being able to create a filter chain including
dependency injection is handy. The downside to this is that some users
may end up spending time writing filters and mucking with the chain,
rather than writing interceptors since familiarity with filters may be
more likely for new users.
On Sat, 2008-06-21 at 12:58 -0400, Musachy Barroso wrote:
+1, way easier to read and understand.
musachy
On Sat, Jun 21, 2008 at 11:21 AM, Don Brown <[EMAIL PROTECTED]> wrote:
> I've committed a new filter dispatcher strategy that aims to:
> * Make it crystal clear to users how to deploy Struts
> * Make it crystal clear to developers what filters are doing what
> processes
> * Better enable customizations and overrides by advanced users
>
> This first cut is more about tackling the first two issues, and I'd
> like to get some feedback on them. There are a number of tickets that
> are caused by buggy and confusing filter dispatchers and their
> deployments, as well as I have a need to have our dispatch process be
> more flexible to support things like native operation in OSGi or in a
> plugin system.
>
> You'll notice that there is certainly more code in this new design,
> however, I'm hoping it is self-documenting, brain-dead code that is
> easier to read and follow. I've outlined how it would be used in the
> package Javadocs:
>
> Simple Dispatcher
>
> <filter>
> <filter-name>struts2</filter-name>
>
> <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>struts2</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
>
> Deployment with Sitemesh
>
> <filter>
> <filter-name>struts2-prepare</filter-name>
>
> <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareFilter</filter-class>
> </filter>
> <filter>
> <filter-name>sitemesh</filter-name>
>
> <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
> </filter>
> <filter>
> <filter-name>struts2-execute</filter-name>
>
> <filter-class>org.apache.struts2.dispatcher.filter.StrutsExecuteFilter</filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>struts2-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts2-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> So basically, a one-to-one, filter to usecase mapping. Please take a
> look at the code as I'd like to get this finalized in the next few
> days:
>
>
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/filter/
>
> Thanks,
>
> Don
>
> PS. We are 46% of the way to GA 2.1 release...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
