tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Interceptors ( was Re: 3.x vs 4.0 architecture Q's
Date Thu, 18 Jan 2001 20:56:20 GMT
> Looking at the latest 3.x src drops, there are say ~30 methods in
> BaseInterceptor, that is access points, into the request chain  / context
> mapping / session handling etc. This obviously gives a degree of

Hi Ken,

All this will be reviewed and documented - if the release proposal is
accepted. I would really like to have the 3.x Interceptors discussed in
detail and any sugestion incorporated ( before the proposed beta). 

> control/access to the internals, though does raise the question, how many
> are enough? Are those enough because they now cover all the functionality a
> server does? Or will a few extra be needed as time goes on? This seems a

Apache 1.3 needs about 15, and was able to do everything it does using
only those.

Apache 2.0 provides a mechanism to add more - the so-called HOOKS. 

The current tomcat 3.x hooks need to be reviewed to make sure we have all
we need. I wouldn't mind adding few more ( before beta ), or removing any
that reviewers feel is not needed. 

> bit brittle to me. If an extra method is added, presumably that means a new
> hook into an internal api, and the code to support it. Does this mean
> multiple interfaces / base classes are required? All pluggable? What about
> the existing interceptors people have written? It would be really good to
> hear an argument for this design? What are the benefits of it? Does it
> gives the server internals better control / optimisation opportunities?

Adding a method is backward-compatible, and in general doesn't require
recompilation for existing interceptors. 

All of the tomcat3.x functions are now implemented in modules - so it's
not likely we'll need many more hooks. Given that all  Apache 1.3
modules used only 15 ( or less ? ) means that we should be fine. 

My experience was that adding a hook is greatly simplifying the code and
allows better organization. A good example is the handleError() hook that
allowed to turn all the (complex) error handling code in a module.

I had a (working) prototype implementing an extensible mechanism similar
with Apache2.0, but my belief is that it isn't needed in the context of
the proposed 3.3. ( it was developed early in 3.2 days, so it's now
out-of-date, but I can publish it if you want to take a look ).

> Costin's arcticle mentioned that the Handler/Wrapper classes actually allow
> 3.x to use valves -- is this a clean interface (I confess to not having got
> that far yet) ? As simple as 4.0? It also states that some of the current
> Interceptors were / could have been Valves, but but were chosen not to be,
> but does really explain why.

Handler has the invoke(), setNext, setPrevious methods similar with
Valve. I'll add more explanations in the documentation - after the whole
release plan issue is resovled. ( please remind me :-). The design patter
is the same ( chain of command), except that Interceptors provide multiple

The main reason for writing the current modules as Interceptors was
the fact that Apache modules are using the same model - and it was felt
that this will help with the integration ( "advanced" integration can be
greatly simplified by using the same model ). 


View raw message