> 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
chains.
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 ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
