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]
