struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Struts Two <>
Subject Re: Benefits of using Filter as front controller
Date Tue, 14 Aug 2012 13:46:33 GMT
What people are missing here is that using filters and deviating from the spec as front controller
would cause quite a few issues when some applications servers are used. I quite clearly remember
that I went through hell to deploy my applications on WebSphere applications with an Http
server as front Web server. WebSphere goes through web.xml files and uses Servlet URL mappings
to generate the plugin file for resource mapping and filters are ignored. Even when I opened
a pmr, I was told by support that struts 2 deviates from the Spec. when you pick a framework,
you got to be aware that these things may cost you dearly down the road depending on what
application servers you use or you plan to migrate.

As much as I have been an avid struts user [specially struts 1], I personally think that you
should seriously consider Spring MVC / MVC Portlet against any other framework. I ,per se,
have had a great experience with Spring MVC which somehow brings up the good memories of struts
1 [once everything is put in the context of its time]

----- Original Message -----
From: "" <>
To: Struts Users Mailing List <>
Sent: Monday, August 13, 2012 2:05:45 PM
Subject: Re: Benefits of using Filter as front controller

Thanks for such a detailed explanation and descrbing each and every aspects
Now even I can say and explains things in much more and good way
Sent from BlackBerry® on Airtel

-----Original Message-----
From: Rene Gielen <>
Date: Mon, 13 Aug 2012 20:00:04 
To: Struts Users Mailing List<>
Reply-To: "Struts Users Mailing List" <>
Subject: Re: Benefits of using Filter as front controller

Grabbed me a copy of Servlet Spec 2.4:

SRV.6.1 What is a filter?
A filter is a reusable piece of code that can transform the content of
HTTP requests, responses, and header information. Filters do not
generally create a response or respond to a request as servlets do,
rather they modify or adapt the requests for a resource, and modify or
adapt responses from a resource.

"do not generally" is way different from "may not", right?

Reading both the relevant parts of the spec and the API docs again, I
cannot see any violation of the servlet specification by using a Filter
for doing the dispatching, rather than a Servlet.

The other part is how requests are mapped, which imposes the question if
a servlet mapping matching the request URL must exist:

SRV.11.1 Use of URL Paths
1. The container will try to find an exact match of the path of the
request to the path of the servlet. A successful match selects the servlet.
2. The container will recursively try to match the longest path-prefix.
This is done by stepping down the path tree a directory at a time, using
the ’/’ character as a path separator. The longest match determines the
servlet selected.
(ad 2.: Previous versions of this specification made use of these
mapping tech- niques as a suggestion rather than a requirement, allowing
servlet con- tainers to each have their different schemes for mapping
client requests to servlets.)
3. If the last segment in the URL path contains an extension (e.g.
.jsp), the servlet container will try to match a servlet that handles
requests for the extension. An extension is defined as the part of the
last segment after the last ’.’ character.
4. If neither of the previous three rules result in a servlet match, the
container will attempt to serve content appropriate for the resource
requested. If a "default" servlet is defined for the application, it
will be used.

Point 4 is crucial. As to my opinion, it doesn't state clearly if a
default mapping must exist or not, which leaves it IMO up to the container.

That said, most frameworks use dispatcher servlets, and WebWork / Struts
2 once did as well.

The rationale behind switching to the Filter architecture was to deal
better with integrating technologies such a Sitemesh or Portlet, which
both profit from splitting the dispatching in more than one phase. This
could only be accomplished by using filters rather than servlets. Since
then, e.g. all major problems with sitemes integration magically

So my point of view is that there is nothing wrong with using filters
for dispatching. If the container interprets the servlet spec in an
opposite way, a dummy default servlet mapping should do the trick.

Nevertheless I'm happy to hear about points I might have missed or

- René

Am 8/13/12 16:01 , schrieb Paul Benedict:
> I'll take back what I said and reserve opinion until further research.
> I'll be interested in what you all find. For the record, the Spring
> Framework has its front-controllers as servlets.

> Paul
> On Mon, Aug 13, 2012 at 8:53 AM,  <> wrote:
>> Yes this was one of the point I was thinking
>> Same question was today asked on SO and this lead me to reaseach as what advantages
and reasons was there to use filter as controller
>> Sent from BlackBerry® on Airtel
>> -----Original Message-----
>> From: Dave Newton <>
>> Date: Mon, 13 Aug 2012 09:49:43
>> To: Struts Users Mailing List<>
>> Reply-To: "Struts Users Mailing List" <>
>> Subject: Re: Benefits of using Filter as front controller
>> IIRC it states filters shouldn't be used to serve resources. I can't look
>> it up at the moment, but will later today.
>> Dave
>> (pardon brevity, typos, and top-quoting; on cell)
>> On Aug 13, 2012 9:44 AM, "Paul Benedict" <> wrote:
>>> With all due respect, I think saying Struts 2 violates the Servlet
>>> Spec is a grand stretch of the imagination.
>>> Struts has a filter gives greater control over the kind of dispatching
>>> needed. You can then intercept processing not just web requests, but
>>> forwards, includes, and container errors. See the <dispatch> child on
>>> the <filter> element in web.xml. AFAIK, these advanced interception
>>> techniques are not available
>>> Paul
>>> On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty <>
>>> wrote:
>>>> A good question!
>>>> The issue of "direct access of filters as resources" does appear to
>>> break the 2.4 Servlet spec for the reason that Struts needs access to all
>>> (attributes)
>>>> from the Request
>>>> Another important issue is "who is doing the dispatching" under Strut2
>>>> Martin
>>>> ______________________________________________
>>>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>>>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
>>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
>>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
>>> dient lediglich dem Austausch von Informationen und entfaltet keine
>>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
>>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>>>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
>>> le destinataire prévu, nous te demandons avec bonté que pour satisfaire
>>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
>>> de ceci est interdite. Ce message sert à l'information seulement et n'aura
>>> pas n'importe quel effet légalement obligatoire. Étant donné que les email
>>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
>>> aucune responsabilité pour le contenu fourni.
>>>>> Date: Mon, 13 Aug 2012 11:30:05 +0530
>>>>> Subject: Benefits of using Filter as front controller
>>>>> From:
>>>>> To:
>>>>> Hi All,
>>>>> I was reading this thread

>>>>> regarding the intentions of using Filter as front controller while it
>>> seems
>>>>> to violate even *Servlet specification*.
>>>>> Can any one throw light on this?
>>>>> --
>>>>> With Regards
>>>>> Umesh Awasthi
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

René Gielen 

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message