No, sorry, I should have been more specific... This is what I am talking about -
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/filter/DelegatingFilterProxy.html There is a bit more information here - http://springtips.blogspot.com/2007/07/step-by-step-spring-security-aka-acegi.html You map requests to the "filter chain proxy" which points to other filter beans defined in applicationContext.xml. These filter beans are the same as filters written to the servlet spec, but the difference is that since spring instantiates them, they will get all their dependencies. The other key difference is that they are defined and configured within spring. What ACEGI does is a bit too much, especially considering the dependency on Spring (which we'd want to keep out of struts2-core). I was just thinking that maybe a similar approach could be used... If the filter dispatcher loads a list of filters, honoring the order they are specified, sprinkle in a little struts-magic while loading so that @Inject will work on the loaded filters. Then, requests will pass through them. This is very similar to our interceptor stack, and right now, if Don's goal is to resolve some of the ambiguity (necessity of ActionContextCleanup, etc.), then this is overkill. But, maybe down the line if other use-cases crop up where advanced filter configuration becomes necessary, then this is an approach we can consider. On Sat, 2008-06-21 at 19:27 -0400, Bob Tiernay wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
