Hi Pete,
My goal is to explain why and how interceptors are used in
tomcat3.x. While other solution exist,
the design of tomcat3.x is based on certain design patterns that have
certain advantages ( and disadvantages).
The reasons for choosing this pattern:
1. One of the goals is to integrate with web servers.
Using similar design patterns with those used in all major servers is
supposed to simplify this and make possible special optimization. A
different pattern would create an impedance mismatch.
2. This model is well tested in production web servers.
3. Apache evolution is a very important lesson. The direction is clear in
introducting more hooks - and the benefits are highly visible in
Apache 2.0 where amazing modularization happened ( MPM, http as a module,
etc).
4. Reusing the existing patterns should make easier for people to develop
modules - the skills for building IIS filters or Apache modules are
similar with those for building tomcat modules.
5. During tomcat evolution from 3.0 to (proposed) 3.3, adding more hooks
proved to greatly simplify the code and improve performance.
6. Performance. We'll have much shorter and specialized chains, and only
the hooks that are needed will be called. For example, it may not be
needed to call the authenticate method if the request doesn't need that
( even if the request includes authentication info ).
7. Scalability (!). When you have 10 modules, life is simple. When you
have almost 50 - things are different. Apache has much more, and in 2
years we may also get quite a few.
The question is - is it better to fit everything in one hook or to have
specialized chains ?
I would like to mention that both models are possible in tomcat 3.x -
by implementing the Handler and extending invoke() you can support the
same programming model.
It is interesting to note that all servers are also making a distinction
between content generators/filters ( that are implemented in the Handlers
- using the invoke() chain ), and SAFs/hooks/request filters that are
specialized processing chains for various server functions ( auth,
mapping, etc).
As another note - someone mentioned AWT and the event model in windows (
where all events treated uniformly and dispatched by an event queue ).
In this analogy, Tomcat3.x is more using the swing model, of specialized
listeners closelt coupled with the event generators.
As a matter of fact, early in tomcat3.2 development I tried to use
Event/Listeners model - but didn't go forward because of the object
allocation was too hard to control. The pattern is the same, just the
implementation as Interceptor is slightly more efficient.
Costin
P.S. Those are just few of the reasons behind the 3.x Interceptors. It
would be great if someone would want to help creating a small document
based on the discussions we had - with the pros and cons. I could also add
few examples, and maybe go into more details about how the most important
chains work ( Error handling, session, auth, mapping )
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
