>> 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
