[Catalina] Revised Interceptor and Valve Implementations

["Craig R. McClanahan" <cm...@mytownnet.com>]

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
                        Container.java Interceptor.java Valve.java
               proposals/catalina/src/share/org/apache/tomcat/core
                        Constants.java ContainerBase.java
                        LocalStrings.properties StandardContext.java
                        StandardEngine.java StandardHost.java
                        ValveBase.java
               proposals/catalina/src/share/org/apache/tomcat/security
                        SecurityInterceptor.java
  Added:       proposals/catalina/src/share/org/apache/tomcat
Pipeline.java
               proposals/catalina/src/share/org/apache/tomcat/core
                        InterceptorValve.java StandardContextValve.java
                        StandardEngineValve.java StandardHostValve.java
  Log:
  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
    Interceptors.

  * 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.

Re: [Catalina] Revised Interceptor and Valve Implementations

[Assaf Arkin <ar...@exoffice.com>]

"Craig R. McClanahan" wrote:
> 
> Assaf Arkin wrote:
> 
> [snip]
> 
> > >   * 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.
> >
> > Does that mean Valves will only work with certain containers? Are Valves
> > defined as independent connectors (like Interceptor), or as a property
> > of a certain container type (say, ValveCapableContainer)?
> >
> 
> If a Container wants to support Valves, it must implement Pipeline, which you
> can check with "instanceof".
> 
> In practice, any Container that is derived from the convenience base class
> (ContainerBase) will support Valves, because support is automatically
> included there.  It's easier to use this (and thereby support Valves) rather
> than implement all of Container yourself.

Container implements Pipeline is the way to know if Valves are
supported, ContainerBase is one default implementation, or write you
own. Elegant and simple.

arkin


> 
> [snip]
> 
> >
> > arkin
> >
> 
> Craig
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: [Catalina] Revised Interceptor and Valve Implementations

["Craig R. McClanahan" <cm...@mytownnet.com>]

Assaf Arkin wrote:

[snip]

> >   * 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.
>
> Does that mean Valves will only work with certain containers? Are Valves
> defined as independent connectors (like Interceptor), or as a property
> of a certain container type (say, ValveCapableContainer)?
>

If a Container wants to support Valves, it must implement Pipeline, which you
can check with "instanceof".

In practice, any Container that is derived from the convenience base class
(ContainerBase) will support Valves, because support is automatically
included there.  It's easier to use this (and thereby support Valves) rather
than implement all of Container yourself.

[snip]

>
> arkin
>

Craig

Re: [Catalina] Revised Interceptor and Valve Implementations

[Assaf Arkin <ar...@exoffice.com>]

>   * 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
>     Interceptors.

+1


>   * 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.

+2


>   * 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.

Does that mean Valves will only work with certain containers? Are Valves
defined as independent connectors (like Interceptor), or as a property
of a certain container type (say, ValveCapableContainer)?


>   * 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().

I'll have to trust you on that one ;-)

arkin

> 
>   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.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org