tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject [Catalina] Revised Interceptor and Valve Implementations
Date Mon, 24 Jan 2000 08:35:59 GMT
The Catalina proposal's classes (in the CVS tree under
"proposals/catalina") have been substantially revised based on
discussions about the Interceptor and Valve design patterns over the
last few days.  Unfortunately, the line limit on the CVS check-in
notification was exceeded -- here's the log message I recorded:

craigmcc    00/01/24 00:31:32

  Modified:    proposals/catalina/src/share/org/apache/tomcat
  Added:       proposals/catalina/src/share/org/apache/tomcat
  Several major changes, based on discussions regarding the Interceptor
  design pattern in Catalina.  NOTE:  No changes yet based on the
  discussions about configuration design patterns -- those will be next.

  The changes include:

  * The Interceptor design pattern has been refined such that an
    Interceptor's postService() method receives notification of any
    exception thrown by an application servlet, but not by other

  * The Valve pattern has been formally integrated, and an example
    Valve (InterceptorValve) included that provides the Interceptor
    design pattern for those who prefer it.  A convenience base class
    (ValveBase) means you normally only need to implement the
    invoke() method for a particular Valve.

  * Support for Valve pipelines in a Container is now optional, and
    is present only if the Container also implements the new Pipeline
    interface.  The ContainerBase class, which is commonly used as a
    base class for Container implementations, supports this capability.

  * The basic invoke() logic for each of the Container implementations
    included so far (StandardEngine, StandardHost, and StandardContext)
    has been extracted into a separate Valve, according to the Valve
    design pattern.  As a result, Containers now no longer need to have
    an explicit service() method -- every place that request processing
    is desired now means you call invoke().

  Obviously, none of this code is tested yet - the purpose at this
  point is to nail down the design patterns we want to use.  However, if

  you see any glaring logic errors, please do not hesitate to point
  them out.

View raw message