On Sat, 7 Dec 2002, RXZ JLo wrote:
> Date: Sat, 7 Dec 2002 05:02:24 -0800 (PST) > From: RXZ JLo <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: static url routing > > > --- "Craig R. McClanahan" <[EMAIL PROTECTED]> 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. > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
