Thanks for this information, very interesting - seems like we're not alone with FiterDispatcher :)
- René Am 15.08.12 00:45, schrieb Joseph Mocker: > 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 > -- René Gielen IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Tel: +49-(0)241-4010770 Fax: +49-(0)241-4010771 Cel: +49-(0)163-2844164 http://twitter.com/rgielen --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
