struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Belingueres <belingue...@gmail.com>
Subject Re: [OT] Not using servlet class??
Date Fri, 22 Jul 2011 02:23:49 GMT
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 <thechrispratt@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 <davelnewton@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.mca@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-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message