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
