tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Evil" <>
Subject Re: RequestDispatcher.forward() and filters
Date Sun, 11 Nov 2001 00:35:33 GMT

Thanks Craig.  That decisively answers the question for me.  It looks
like, in my application, filters are more useful than servlets.  The
problem with servlets is that if I want to catch all requests, and I
put in a /* mapping, then if I get a RequestDispatcher to anything
else, it will loop back to the original servlet, over and over.
Filters avoid this problem.  Filters are a very powerful thing, more
powerful than servlets, I think.

Here's my current thought on how to design my project:

Create some object (or objects) which live in the ServletContext.
These will hold all the data which the application will need.

Create some filters to generate per-request objects from the object in
the ServletContext, and then install these objects into the Request

Use taglibs to display things as necessary.

This all uses filters; servlets are hardly used in this.

This way there is absolutely no JSP stuff used in the display, and the
model is held in the objects which are in the ServletContext.  Is this
a good design to take advantage of API 2.3?


Craig wrote:
> There are a couple of questions here that are worth answering
> specifically, based on the final version of the 2.3 spec:
> * Can a Filter call a RequestDispatcher?  Yes -- for example,
>   you could implement an MVC-style controller (similar to the
>   Struts ActionServlet) as a Filter that used individual servlets
>   as Actions.
> * If a Filter calls a RequestDispatcher, does that stop the
>   current Filter chain?  Only if you don't call chain.doFilter()
>   after the RequestDispatcher.forward() or RequestDispatcher.include()
>   call returns.  It's up to you to decide whether to continue the
>   chain or not.
> * On a RequestDispatcher call, does the newly selected servlet get
>   its own filter chain?  No -- filter chains are only constructed based
>   on the original request URI.  Servlets that are selected via a
>   RequestDispatcher are invoked directly, with no further filters
>   involved.  (This is also true for RequestDispatcher calls from
>   servlets.)

To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message