FWIW, JAX-RS/Jersey provides both a Filter and a Servlet option as a
controller, however the Servlet came first.
http://java.net/jira/browse/JERSEY-122
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."
--joe
Joseph Mocker | Velti | Senior Software Architect
t +1.650.566.7033 m +1.408.676.6625
e jmoc...@velti.com @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 <struts...@yahoo.ca> 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 <rgie...@apache.org>
>> To: Struts Users Mailing List <user@struts.apache.org>
>> 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: "umeshawas...@gmail.com" <umeshawas...@gmail.com>
>>> To: Struts Users Mailing List <user@struts.apache.org>
>>> 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 <rgie...@apache.org>
>>> Date: Mon, 13 Aug 2012 20:00:04
>>> To: Struts Users Mailing List<user@struts.apache.org>
>>> Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
>>> 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
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
