struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Gielen <rgie...@apache.org>
Subject Re: Benefits of using Filter as front controller
Date Tue, 14 Aug 2012 16:10:56 GMT
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: "umeshawasthi@gmail.com" <umeshawasthi@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 <rgielen@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message