TC3: New hooks ( chains )

[cm...@yahoo.com]

Hi,

Interceptors are the base of tomcat extensibility and modularization. They
implement the Chain of Responsibility pattern and are similar (
identical) with Apache hooks, etc.

So far we tried to keep the number of hooks limited. The initial idea was
to mirror the hooks used in Apache, but we had to add servlet-specific
hooks too ( like preService, preInit, etc). 

Based on the current experience, a big problem seems to be ordering. The
Interceptors must be called in a certain order, as few interceptors depend
on a certain state.

A second issue is tomcat consistency - for adapters we use now
Interceptors ( and that allow interceptors to participate in all request
phases ), but we also extend Request/Response. All current interceptors
follow a simple pattern - they override doWrite, doRead, and have code to
set the initial state of the request and to send headers before the first
write. 

I have few proposals that will improve this:

1. Add more hooks - each hook will represent a state in the request
processing, and we should be able to define what is set and what is not,
and what is the role of each hook. 
This will make the order of hook configuration un-important, and will make
clear what happens in tomcat ( XXX state UML diagram  :-).
For example we can have a "autoConfigure" hook that will allow
auto-configuration of contexts ( the current webapps based solution and
maybe other mechanisms), etc. We'll add as many hooks as needed in order
to eliminate the ordering - as long as each state is clearly defined we
should be ok. 
( recent changes in hook chains make the dimension and number of hooks
unimportant as performance )

2. Add serverWrite() and serverRead() hooks to replace doRead() and
doWrite(). That will eliminate the need to extend Request/Response just to
override the 2 methods, and will make everything more consistent. (
Request/Response can still be extended, of course, but the common case
will be easier to handle )

3. If needed ( i.e. if (1) will introduce too many states or states that
are hard to define ) we can add the same mechanism as in Apache ( FIRST,
BEGINNING, END, LAST), and if that is not enough we can use the NES
mechanism ( explict ordering for each operation ). We want to keep tomcat
as simple as possible, so it's worth to try state-only first ( and we
can't know in advance if this will work or not ). 

Let me know if you need more informations and your opinion.

Costin