tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: static url routing
Date Sat, 07 Dec 2002 17:44:37 GMT

On Sat, 7 Dec 2002, RXZ JLo wrote:

> Date: Sat, 7 Dec 2002 05:02:24 -0800 (PST)
> From: RXZ JLo <>
> Reply-To: Tomcat Users List <>
> To: Tomcat Users List <>
> Subject: RE: static url routing
> --- "Craig R. McClanahan" <> wrote:
> >
> >
> > You actually *can* avoid entering a servlet, so
> > Filter is a very practical
> > way to do "redirect" type things, especially in the
> > same webapp.
> >
> >
> Okay. Does mean I can use the Filter interface
> carefully instead of Servlet interface, and still act
> as a servlet?

You could actually do this if you wanted to.

> Is there any harm in doing this - is
> Filter too handled by the Servlet container in the
> same way as a servlet(for eg, load once and use same
> instance for all requests).

Yes, filters are instantiated by the container the first time they are
needed, and have init() and destroy() methods that are called at the
usual times, just like a Servlet.

I imagine that there might be small performance differences today (I know
there is one in Tomcat 4.x because of the way the FilterChain is managed)
simply because filters are new and the container vendors haven't
necessarily optimized as heavily as they have for servlets, but that's a
very transient sort of issue.

> Is the servlet interface redundant then or am I missing something here?

Interesting question.

For existing applications, the Servlet interface is by no means obsolete
-- the introduction of Filters lets you implement the Decorator design
pattern around your existing applications, and add customizations without
having to impact the existing code.

For new applications, it's basically feasible (but see below) to write
your entire application in terms of Filters, using filter mappings to
compose the processing units for a particular request using the Chain of
Responsibility design pattern.  (You see basically the same pattern inside
Tomcat 4, by the way, if you look at the way that Tomcat uses Valves to
implement much of its request processing functionality.)

This technique requires you to ensure that at least one of the Filters you
configure assumes responsibility for actually creating the response.  It
is also harder to learn Filters than Servlets because of the additional
concepts (what's a FilterChain?  when do I call chain.doFilter()?) -- and
these concepts are overkill in relatively simple applications.  Therefore
I think Servlet will stick around for a long time as a starting point
concept (at the minimum).

[The "see below" note] In Servlet 2.3, there is one fundamental limitation
to using Filters as a general purpose replacement for Servlets -- when you
use a RequestDispatcher.include() or RequestDispatcher.forward() call to
invoke an alternate servlet, filters associated with the alternate path
are *not* invoked.  Among other things, this makes filters less useful
than they could be in MVC-style architectures that flow requests through a
controller servlet.

In Servlet 2.4 (currently in proposed final draft state in the JCP, and
being implemented in Tomcat 5.0), this limitation is being addressed.
You'll have the ability to declare that filters matching the alternate
path are invoked on RequestDispatcher calls, as well as on the original
request mapping.

> thanks,
> rf.


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

View raw message