Interceptor state management

[Conor MacNeill <co...@m64.com>]

Hi,

I have been thinking about the new Interceptor concept and wondering about
state management. I am guessing that in general interceptors will have some
state information and I have been wondering where they might store that
information. It seems to me that some interceptors would want to store state
information in the container, perhaps making that state available to other
interceptors processing requests for that container. In that case we would
want addAttribute(), getAttribute(), etc methods added to the container.
What do you think?


--
Conor MacNeill
conor@m64.com
M64 Pty Limited

Re: Interceptor state management

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

Conor MacNeill wrote:

> Hi,
>
> I have been thinking about the new Interceptor concept and wondering about
> state management. I am guessing that in general interceptors will have some
> state information and I have been wondering where they might store that
> information. It seems to me that some interceptors would want to store state
> information in the container, perhaps making that state available to other
> interceptors processing requests for that container. In that case we would
> want addAttribute(), getAttribute(), etc methods added to the container.
> What do you think?
>

It would certainly be feasible to add attributes as you propose.  What I'm not
quite so comfortable with is making stuff available to the other interceptors --
IMHO interceptors should be designed to be as independent as possible.  However,
given that they do know what container they are connected to, they can share
state (and other side effects) via the container's facilities.

For private state, the interceptor would use instance variables -- one of the
nice simplifications that comes from having an interceptor that is tied to one
and only one container.  Suitable interlocks are required for thread safety, of
course, but you don't have to worry about maintaining state related to multiple
containers at the same time.

One important question that hasn't really been discussed yet is the lifecycle of
an Interceptor.  How in the heck do you configure one of these things?  The
thinking I've had so far is that Interceptors (and pretty much every other major
component in Tomcat.Next) would optionally implement the "Lifecycle" interface
that has three methods -- configure(Node node), start(), and stop().
Configuration information would typically come from something like this in the
server.xml file:

    <Context .......>
        <Interceptor className="MyInterceptor" arg1="value1" ... />
    </Context>

In the configure() method for the Context, it would run into the Interceptor
node as it is configuring itself, and dynamically instantiate an instance of the
specified class.  If that instance itself implements Lifecycle, then it's
configure() method is called, passing the <Interceptor> node.  There, the
interceptor will configure itself based on the attributes.  Although not shown
in this example, the configuration process can be recursive -- which is really
elegant if your component hierarchy is fully nested in the same way that XML
elements can be.

After everything has been configured, the container goes back and calls start()
on all the components that implement Lifecycle (in the same top-down order they
were configured), and processing begins.  Finally, when you need to shut down,
the stop() method of all the components that implement Lifecycle are called --
so you can gracefully release resources that you allocated in your start()
method.

Interceptors (and other components) are not required to implement Lifecycle, so
the code that creates new components needs to check for that.  Such components
are assumed to configure themselves based on some other mechanism.

> Conor MacNeill
>

Craig McClanahan