struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Mocker <>
Subject Re: Benefits of using Filter as front controller
Date Tue, 14 Aug 2012 22:45:58 GMT
FWIW, JAX-RS/Jersey provides both a Filter and a Servlet option as a controller, however the
Servlet came first.

Note the bug mentions Wicket also uses a Filter. The bug also provides an interesting reason
for the use of a filter

        to intercept "all HTTP calls against a path but only consumes those calls it can handles.
All other calls are
        allowed to continue and get handled by another Servlet or Filter."


Joseph Mocker   |   Velti   |   Senior Software Architect
t +1.650.566.7033   m +1.408.676.6625
e   @Mobclix

The leading global technology provider of
mobile marketing and advertising solutions

On Aug 14, 2012, at 12:41 PM, Rene Gielen wrote:

> No worries, always good to question - review - rethink
> If there is serious interest in an alternative servlet dispatcher besides FilterDispatcher,
contributions are welcome. From the top of my head, the old dispatcher is still around as
deprecated, and most of the dispatcher functionality resides in a delegate.
> - René
> Sent from my iPad
> On 14.08.2012, at 20:21, Struts Two <> wrote:
>>>> I remember more than one case where I found WAS / Websphere Portal to implement
a very ... say ... at least ... imaginative interpretation of the specs
>> That is exactly the point,the compromise of "clear-cut" sections of spec in favor
of "unclear, murky, interpretive" sections of spec in struts 2 much like IBM. There is no
"interpretation" on whether a Servlet can/should be used to server resource but when it comes
to filters there is. And quite rightfully so,  as there may be darn compelling reasons to
do so, since things quite few often do not follow patterns put in black and white. I am not
trying to stir an endless discussion on what interpretation is correct as there will be no
consensus. And I do not know what has been the darn compelling reason that could have not
gotten away with using a Servlet as front controller in struts 2, but I would have loved to
have the option of using a Servlet as my front controller in struts 2.
>> With all said, I did not mean to belittle struts 2 or take a jab at any struts 2
contributor in my previous comment. And I believe it is very honorable of you to try make
the tool available to the development community for free by putting a lot of work in your
free and personal time. I just wanted to reflect the opinion for some spectrum of struts user
community though may be small in numbers.
>> ----- Original Message -----
>> From: Rene Gielen <>
>> To: Struts Users Mailing List <>
>> Cc:
>> Sent: Tuesday, August 14, 2012 12:10:56 PM
>> Subject: Re: Benefits of using Filter as front controller
>> So far I fail to see where Struts 2 deviates from or violates the spec.
>> The fact that _usually_ a front controller - a concept not to be found
>> at all in the servlet spec - is implemented as servlet does not mean
>> that it _has_ to be implemented that way, unless the spec says or
>> clearly implies otherwise. For what I found in the and cited earlier,
>> this is not the case.
>> That WAS *interprets* the spec in a different way - especially when it
>> comes to a tooling level that has nothing to do with the spec whatsoever
>> (parsing web.xml to generate loadbalancing / proxy webserver
>> configuration) - is a totally different story. To some extent I
>> understand the rationale behind this, implying a servlet mapping should
>> exist for a given URL - but besides IBM claiming this has to be the
>> case, I haven't found any evidence so far. Interestingly, when it comes
>> to IBM support saying Struts 2 deviates from the spec, I remember more
>> than one case where I found WAS / Websphere Portal to implement a very
>> ... say ... at least ... imaginative interpretation of the specs. I'm
>> not quite sure if them saying that Struts 2 deviates makes a case for
>> this being a fact to count on. But again, I'm happy to hear I'm wrong if
>> someone could clearly point out what I might have missed when reading
>> the spec.
>> Side note - sorry to say, but in my very personal and for sure not
>> representative experience, every time a "some application servers might
>> have issues" case arises, there is a good chance that _some_ of them
>> share a common product line name, starting with "W" :) And well, going
>> through hell when deploying apps to WAS* is something I suffered from
>> myself many times, with various different frameworks and technology
>> stacks in use.
>> I'll try to wrap up my points:
>> - the filter-based dispatching addressed real and serious technical
>> integration issues, and was able to solve them
>> - if it would violate the spec, we would *have to* remove it again, or
>> at least deliver a then spec conform dispatcher servlet as alternative -
>> so far there seems to be no evidence this is the case
>> - the Struts team *can for sure do much better* in documenting the
>> possible glitches, especially after what we learned from this thread and
>> your experiences; we should point out that using a filter dispatcher
>> might impose the need to add a default dummy servlet mapping to help
>> some application servers
>> BTW: I agree, Spring MVC became a great framework once they dropped the
>> inheritance-based controller madness, replacing it with annotation based
>> POJO configuration and heavy AOP magic. Nevertheless, Struts 2 has a lot
>> of sweet spots even over Spring MVC, as to my opinion as a user of both :)
>> Cheers,
>> - René
>> Am 14.08.12 15:46, schrieb Struts Two:
>>> 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 <>
>>> Cc:
>>> Sent: Monday, August 13, 2012 2:05:45 PM
>>> Subject: Re: Benefits of using Filter as front controller
>>> Rene
>>> 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:
>>> <quote>
>>> 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.
>>> </quote>
>>> "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:
>>> <quote>
>>> 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.
>>> </quote>
>>> 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
>>> disappeared.
>>> 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
>>> misinterpreted.
>>> - René
>> <snip/>
>> --
>> 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:

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

View raw message