> Okay, I appreciate if you can take a look at it. I must admit I have not
> looked at the interceptor stuff enough to see how it should be done. To
> me, "interceptor" sounds like something that intercepts a specific request
> and does something with it, not a component that can provide an interface
> to non-request related internal functions.
Yes, the documentation of tomcat3 is very bad...
"Interceptor" is (or tries to be ) equivalent with an Apache
module. Almost all of the tomcat's functionality ( parsing URLs, maps,
authentication, class loaders, reloading, error handling - in 3.3,
configuration, etc) is implemented in "modules" or "interceptors".
In 3.3 we also implement server connectors ( HTTP, AJP ) as Interceptor -
again mirroring a bit Apache ( and MPM ).
The interceptor is a collection of hooks / notifications - for everything
that happens in tomcat and for every functionality that is needed we have
a hook, and people can define a module that will use that hook to
implement the functionality in a particular way.
In theory ( and what happens in Apache, IIS, NES ) all extensions should
be implementable as modules ( + the core == a small set of classes
representing common server objects ). JSSI is a good test case - from what
I read I think we forgot one hook ( to notify when a new servlet is
defined/added to the server - so that the JSSIInterceptor can implement
isServletDefined ).
Note that isServletDefined can be implemented either as a call to a
component that manages servlets, or by maintaining a private
structure (hashtable). The second choice is very important because it
doesn't force a particular data structure for modules - the core can
only use JDK1.1 tools, while a module can use JDK1.2 collections or
specialized structures.
Costin
