You can do the same thing with a servlet, just invoke the action in the servlet. The original WW used a servlet, the filter is relatively new.
Dave On Jul 21, 2011 10:24 PM, "Gabriel Belingueres" <belingue...@gmail.com> wrote: > Being a Filter, it allows the developer to add functionality either > before of after the request, while that being a Servlet it only allows > to add functionality before...either way the odds are that the > functionality is not Struts-related or Struts-dependent, because > otherwise AFAIK it seems simpler to write an interceptor to do the > job. > > Maybe, for completeness, the solution could be to factor out the S2 > entry point to another class and implement the usual Filter and a new > Servlet class (both of them delegating to the same object), letting > the developer to choose which one to use, however I can't see right > now the gain in doing this (seems there is not any real use case for > this change). > > Regards, > Gabriel > > 2011/7/21 Chris Pratt <thechrispr...@gmail.com>: >> I'm not sure if this played into the original motivation, but it does make >> WebWork/Struts2 more flexible. Since you can actually use it as a filter >> for another Servlet. You just define what rules trigger the Struts Filter >> and the rest get processed by the Servlet. If Struts2 was a Servlet itself, >> you wouldn't have that option. >> (*Chris*) >> >> On Wed, Jul 20, 2011 at 7:12 PM, Dave Newton <davelnew...@gmail.com> wrote: >> >>> You'd need to ask the original webwork devs. It's true that the servlet >>> spec >>> specifically states that filters should not be used to serve requests, but >>> as far as I can tell there's no compelling technical reason why that's so >>> stated. >>> >>> Dave >>> On Jul 20, 2011 9:57 PM, "Balwinder" <balwinder....@gmail.com> wrote: >>> > Hi All, >>> > >>> > I just want to understand why in Struts2 request is serviced by sub >>> > class of Filter class rather than specified and standard way of doing it >>> > through Servlet class? >>> > >>> > Regards, >>> > Balwinder Kumar >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> > For additional commands, e-mail: dev-h...@struts.apache.org >>> > >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org >
