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é Am 8/13/12 16:01 , schrieb Paul Benedict: > I'll take back what I said and reserve opinion until further research. > I'll be interested in what you all find. For the record, the Spring > Framework has its front-controllers as servlets. > > http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/servlet/package-summary.html > > Paul > > On Mon, Aug 13, 2012 at 8:53 AM, <umeshawas...@gmail.com> wrote: >> Yes this was one of the point I was thinking >> Same question was today asked on SO and this lead me to reaseach as what >> advantages and reasons was there to use filter as controller >> Sent from BlackBerry® on Airtel >> >> -----Original Message----- >> From: Dave Newton <davelnew...@gmail.com> >> Date: Mon, 13 Aug 2012 09:49:43 >> 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 >> >> IIRC it states filters shouldn't be used to serve resources. I can't look >> it up at the moment, but will later today. >> >> Dave >> >> (pardon brevity, typos, and top-quoting; on cell) >> On Aug 13, 2012 9:44 AM, "Paul Benedict" <pbened...@apache.org> wrote: >> >>> With all due respect, I think saying Struts 2 violates the Servlet >>> Spec is a grand stretch of the imagination. >>> >>> http://stackoverflow.com/questions/2957165/servlet-vs-filter >>> >>> Struts has a filter gives greater control over the kind of dispatching >>> needed. You can then intercept processing not just web requests, but >>> forwards, includes, and container errors. See the <dispatch> child on >>> the <filter> element in web.xml. AFAIK, these advanced interception >>> techniques are not available >>> >>> Paul >>> >>> On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty <mgai...@hotmail.com> >>> wrote: >>>> >>>> A good question! >>>> The issue of "direct access of filters as resources" does appear to >>> break the 2.4 Servlet spec for the reason that Struts needs access to all >>> (attributes) >>>> from the Request >>>> >>>> Another important issue is "who is doing the dispatching" under Strut2 >>>> >>>> Martin >>>> ______________________________________________ >>>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >>>> >>>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >>> dient lediglich dem Austausch von Informationen und entfaltet keine >>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >>>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas >>> le destinataire prévu, nous te demandons avec bonté que pour satisfaire >>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >>> de ceci est interdite. Ce message sert à l'information seulement et n'aura >>> pas n'importe quel effet légalement obligatoire. Étant donné que les email >>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >>> aucune responsabilité pour le contenu fourni. >>>> >>>> >>>>> Date: Mon, 13 Aug 2012 11:30:05 +0530 >>>>> Subject: Benefits of using Filter as front controller >>>>> From: umeshawas...@gmail.com >>>>> To: user@struts.apache.org >>>>> >>>>> Hi All, >>>>> >>>>> I was reading this thread >>>>> >>> http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html >>>>> regarding the intentions of using Filter as front controller while it >>> seems >>>>> to violate even *Servlet specification*. >>>>> >>>>> Can any one throw light on this? >>>>> >>>>> -- >>>>> With Regards >>>>> Umesh Awasthi >>>>> http://www.travellingrants.com/ >>>> >>> >>> --------------------------------------------------------------------- >>> 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 http://twitter.com/rgielen --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
