On Tue, 11 Dec 2001, Donnie Hale wrote:
> Date: Tue, 11 Dec 2001 20:40:41 -0500
> From: Donnie Hale <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Struts & Filters (Servlets 2.3)
>
> Craig,
>
> Could you briefly enumerate the advantages a filter would have over a
> servlet for what ActionServlet *currently* does? I can see how it would be
> useful for certain new features, and I can see how the context lifecycle
> events would be nice to monitor; but I'm not sure I see what a filter buys
> us for ActionServlet's current functionality.
>
The "application managed security" case is a good example. And, you could
even do this one in front of the current controller servlet. Consider the
requirement that you want to act just like container managed security does
(*every* request should be checked for requiring authentication). In a
Servlet 2.2 environment, you can do this for requests through the
controller pretty easily, but you also need to protect each JSP page
individually (like the example app does with the "checkLogon" tag) in case
the user tries to access it directly.
More generally, a Filter would provide for the following features over and
above what the existing controller servlet does:
* You can cascade functionality in multiple Filters, without
modifying the code in the rest of the app. (For example,
we could add an app-managed security Filter like the one
described above in front of *any* servlet based application
-- Struts or not -- with no changes to the rest of the app).
This can vastly simplify the overall architecture of the
controller, and/or let you compose the controller functionality
out of a set of independent filters that just implement the
things you want.
* Filters can wrap the request and response they hand on to
the rest of the app. In our security case, we could make
the application think it was using container-managed security
by making getRemoteUser() and isUserInRole() work as expected),
but without having to use your container's notion of users.
* Filters could segment the URI space into different sub-applications
by being mapped to different patterns (we could do that with
a controller servlet too, of course).
* Filters could be used to perform pre-processing on the request,
and/or post-processing on the response, to perform data transformations
required by the application. The canonical case would be to do
XSLT transformations each way to make the SOAP messages sent by
your trading partner conform to your requirements. (This is similar
to what Cocoon2 can do with a site map.)
* Filters can be used to enforce "users do not have direct access
to a JSP page" if you wanted to be hard-nosed about this part
of the MVC design paradigm. Currently, the only way we can do that
is put the JSP pages under /WEB-INF, which works only as a side effect
of a rule that servlet containers enforce ("no direct access to any
resource under /WEB-INF").
* Filters can let you use existing servlets be used as Actions,
without giving up things like the form bean processing.
* Filters can, in effect, "remap" request URIs the same way you might
use mod_rewrite in Apache. This would be done by having the filter
do a RequestDispatcher.forward() to the resource it thinks you really
wanted, and never forward to the originally selected servlet.
* Filters apply to requests for static content, as well as requests
to the controller servlet and JSP pages, so you can do extra
processing around them as well.
If Struts were originally created on a Filter based framework, there never
would have been a single monolithic controller servlet. Instead, it would
have been an application event listener (to do the startup and shutdown
stuff) plus a set of cooperating filters that can be combined according to
the specific needs of a particular application.
That's probably a reasonably complete starting list, although I'm sure
that I've missed a few interesting possibilities :-).
> Thanks,
>
> Donnie
>
Craig
>
> > -----Original Message-----
> > From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> > R. McClanahan
> > Sent: Sunday, December 09, 2001 8:57 PM
> > To: Struts Developers List
> > Subject: Re: Struts & Filters (Servlets 2.3)
> >
> >
> > On Sun, 9 Dec 2001, Peter Heller wrote:
> >
> > > Date: Sun, 09 Dec 2001 20:36:34 -0500
> > > From: Peter Heller <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Struts & Filters (Servlets 2.3)
> > >
> > > Will there be a subclass created in struts such as actionFilter ?
> > >
> > > Will the Struts filter be part of web.xml or struts-config.xml?
> > >
> >
> > I think the question being asked here is "will the Struts controller
> > functionality (currently implemented in ActionServlet) be implemented as a
> > javax.servlet.Filter from the Servlet 2.3 API?" It's a pretty interesting
> > question.
> >
> > Had the Servlet 2.3 API been available when Struts was originally
> > designed, it's a pretty sure bet that I would have implemented the
> > controller as a Filter instead of as a Servlet. This would have made
> > possible some interesting approaches to using the Struts controller in
> > front of (or in front of part of) existing applications that are being
> > migrated to Struts, as well as the "multiple controllers per webapp"
> > paradigm that we are currently discussing.
> >
> > However, that's not what happened. Struts is currently based on the
> > facilities of Servlet 2.2 and JSP 1.1, because that provides support on
> > the very broad range of application servers that support these APIs. I
> > feel that we ultimately want to migrate to Servlet 2.3 / JSP 1.2 to take
> > advantage of the new facilities -- the quesion is, when?
> >
> > We certainly need to continue to support the ability to run Struts based
> > applications on a Servlet 2.2 / JSP 1.1 platform for the forseeable
> > future. However, there are many compelling features of the next
> > generation APIs that are worth supporting. I'd like to see us explore
> > taking advantage of those capabilities by offering enhanced (or
> > alternative) implementations of the basic Struts controller functionality
> > based on the new APIs.
> >
> > What do the other developers think? Are there enough Servlet 2.3 / JSP
> > 1.2 environments available (obviously, I will be using Tomcat 4 for this,
> > since I'm pretty intimiate with its internals :-) to make development
> > *and deployment* of Servlet 2.3 / JSP 1.2 based applications useful, or is
> > it still a little too early?
> >
> > Even if it's too early, we can start exploring those sorts of ideas so
> > that we're ready when the platforms are readily available.
> >
> > Craig
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
