struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heath Chiavettone" <>
Subject RE: Servlet 2.3 filter
Date Wed, 03 Apr 2002 20:21:53 GMT
Speaking of filtering, Our company is using a filter whose job it is to
handle a multi-part encoded request seamlessly as if it were a regular
request.  What I mean by this is that it reads the multipart stream, builds
the appropriate request parameter map, and handles the upload of files
(sticking the resulting file "object" references into the request as an
attribute with the name of the input element).  Essentially it handles all
of the work of parsing the stream, and allows the JSP page developer to not
have to do anything special when dealing with a multipart file.  They simply
need to ask the request for an attribute to get the file object.

Struts does this using a slightly different mechanism.  I guess my question
is this:

Does it make sense for Struts to adopt a similar mechanism in place of (or
along with) its current one?

Hopefully this question doesn't sound to scatterbrained...


-----Original Message-----
From: Craig R. McClanahan [] 
Sent: Wednesday, April 03, 2002 9:39 AM
To: Struts Developers List
Subject: RE: Servlet 2.3 filter

On Tue, 2 Apr 2002 wrote:

> Date: Tue, 2 Apr 2002 14:33:14 -0600
> From:
> Reply-To: Struts Developers List <>
> To:
> Subject: RE: Servlet 2.3 filter
> Please forgive my ignorance if this is a well-known thing.  I went to
> the Struts BOF and I went to the "Filters can replace Servlets in MVC"
> BOF.  I see the concept, but I just don't see how filters are "better"
> than servlets for MVC.  Is there documentation or discussion about this
> idea somewhere?  I first heard of it at JavaOne.  Is it "pre-supposed"
> that Struts will someday become filter-based or did I misunderstand
> that?  I see how filters are a good frontend to MVC to make sure
> requests don't circumvent your controller, but it doesn't make sense to
> me that a filter would "be" the controller.  What are the community's
> thoughts on that?

This is a really interesting question.

I finally had a chance to review the slides from Kevin Jones's session on
Filters (slides for all the sessions are now available in PDF from -- this was session 1208).

I won't claim that I agree with everything Kevin proposes about using
Filters as a controller in an MVC environment.  In particular, I would not
consider the "hard to track which servlet is associated with which JSP
page(s)" issue to be a problem in MVC.  Rather, I consider that
separation to be (one of) the whole points of MVC -- making the business
logic and presentation logic as independent of each other as possible.

That being said, I can see the following general advantages for using a
Filter as the controller component of Struts:

* UNIVERSALITY - You can actually guarantee that *all* requests really
  flow through the controller.  Consider the following scenarios in
  Struts 1.0 and 1.1:

  - In the Struts example app, we want to ensure that the user is always
    logged on, and redirect to the login page if not (a very common
    requirement in apps that manage their own security).  But, in order
    to accomplish this guarantee, we've got ugly <app:checkLogon> tags
    on all of the pages, because we can't guarantee that the user will
    not link directly to a page.

  - In the multiple application support of Struts 1.1, there is a current
    restriction that all links *must* flow through the controller in order
    for the sub-application selection logic to work correctly.  We could
    get around this by requiring a custom tag on every page again, but
    that is clearly not optimal.

  Both of these situations can be elegantly handled by mapping a
  controller Filter to the "/*" URL pattern, so that it watches every
  single request.

* COMPOSABILITY - The current Struts controller logic is very monolithic,
  and it is hard to customize exactly what the controller does for you.
  If, instead, we viewed the controller as a series of services that can
  be included or not (based on application requirements), the application
  architect has the option to pay for only the services they need.
  Examples of current Struts services that might well be decomposed:
  multipart request handling, path->Action mapping, locale selection,
  role permissions checking, form population and validation, ... plus
  the fact that it would be easy to add other (perhaps application
  specific) services that integrate nicely with those provided by Struts.

* FLEXIBILITY - Another aspect of the monolithic nature of the current
  controller is that all of it's processing is applied to every request.
  While that is sort of the idea of MVC :-), there are many cases where
  you might want different sets of services invoked in different parts of
  the same app (or in different sub-applications).  We went part-way in
  this direction in 1.1, by letting you customize the RequestProcessor
  instance used for each sub-app.  It's much more powerful to allow the
  application architect to compose the set of services to be applied
  in a declarative fashion, in web.xml, without having to write any code
  to manage the overall orchestration.

* INTEGRATION - Sometimes you want to be able to integrate existing web
  application functionality, already provided by servlets and/or JSP
  pages, into a Struts based web app.  Today, you have to write "glue"
  actions that do forwards to such resources -- with a Filter based
  controller that front ends things, you can do this more elegantly
  (even if you can't modify the apps being integrated).

* WRAPPING - A completely different sort of advantage in using a Filter
  is the ability (using the Filter APIs) to wrap the request and/or
  response before handing it on to the next filter (or the servlet that
  ultimately gets invoked).  This capability lets you do all sorts of
  interesting things -- just a couple of ideas to whet your appetite:

  - If you want to do application managed security, but like the idea
    of role checking and user identification that Struts can use in its
    decision making process, you could write a request wrapper that fakes
    the values returned by getRemoteUser(), getUserPrincipal(), and
    isUserInRole().  NOTE - whatever you do here won't affect security
    decisions that the container itself makes (such as EJB access
    permissions), so it's not a panacea.

  - It's commonly necessary to generate slightly different HTML for
    different user agents, to deal with the inevitable differences.
    One approach is to build the knowledge of these differences into
    every tag that renders HTML.  A different approach would be to
    generate some agent-neutral rendering of the output in XML, and then
    apply an agent-specific transformation in a response wrapper.

  Some of this can be done with a monolithic controller model, but it
  tends to be easier if the controller is composed of separate filters
  that you can order as needed.

The bottom line is that, while there has been no formal decision that a
future version of Struts would migrate to a Filter based controller, the
arguments I've listed above seem like fairly compelling advantages.  As
always, we would strive to minimize any impacts on applications that just
*use* Struts (i.e. you've just implemented actions and form beans) -- but
the additional power that could be made available to developers is quite
impressive.  What do you think?

> Greg


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message