tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: [Catalina] Discussion - Interceptor Architecture
Date Thu, 20 Jan 2000 19:54:11 GMT
"Craig R. McClanahan" wrote:
> * Because interceptors are executed in a multithread
>   environment just like servlets are, there is no
>   convenient way to maintain per-request state
>   between the preService() and postService() calls
>   that occur for the same request.

That's a problem of whoever implements the Interceptor. I would like to
see some handle you can use to identify the request, but I don't want to
see an interceptor instance per request model.

If someone needs that sort of implementation, an interceptor can be used
to provide that support to another interceptor.

> * Exception handling is really fragile -- the current
>   Javadocs say that if (say) a Container throws an
>   exception, then the postService() method of all
>   interceptors -- when you already called preService
>   on them -- will be skipped.  This makes it much more
>   difficult to release resources that were allocated
>   in the preService methods.

Exceptions thrown by a Servlet must be held, then interceptors called in
sequence, then the exception should be dealt with. An exception thrown
by a Servlet should not necessarily be thrown back to the container.

If you look at how EJB works, an exception thrown by the EJB bean is not
throw back to the client. The container first does the cleanup
(invalidating the bean, rolling back the transaction), the figures out
which type of exception to throw to the client. Application exceptions
are thrown as is, runtime exceptions are converted to RMIException.

> In the Apache JServ component-based architecture, a different approach
> called "Valves" was taken.  Instead of adding the interceptors into a
> stack, they are added to a linked list instead.  A given Valve would
> either process the request and return, or pass the request on to the
> next Valve in the pipeline (after possibly modifying the request
> parameters).  I have checked in the following files to illustrate the
> Valve interface, and a convenience base class that implements the
> appropriate linking.

I like the Valves design pattern and I use it a lot, but I don't see how
it fits Interceptors. Tomcat should have a stupid and generic design to
hook into interceptor. Internally the interceptor could use Valves and
other design patterns to offer the required services.

So, if you have a plug-in that doesn't like the way Interceptors are
working today, you provide an Interceptor that provides the right
semantics to that plug-in and use it. An adaptor interceptor.


>     proposals/catalina/src/share/org/apache/tomcat/
>     proposals/catalina/src/share/org/apache/tomcat/core/
> This approach seems to meet all of the design objectives of
> Interceptors, and adds some additional features:
> * Per-request state is easy to keep, using local variables
>   in the invoke() method.
> * Exceptions thrown by subsequent Valves or Containers
>   can be caught, so you can gracefully release anything
>   you've allocated.
> * You can even replace the request and/or response
>   objects before calling the next valve in the pipeline,
>   which would give you the ability to implement post-servlet
>   filtering if you really wanted to (I don't like that approach,
>   but it is enabled by this architecture).
> If we like it better than Interceptors, I would propose that
> Interceptors (in Catalina) be replaced by Valves (although I'm pretty
> neutral about which name we keep).  What do we all think?
> Craig McClanahan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message