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
