On Wed, 1 Aug 2001, Christopher Cain wrote:
> I wasn't aware that the <RequestInterceptor> approach was more-or-less the
> deprecated way to interface a module, which would explain some of my confusion.
> Since the newer way sounds not only ... well, newer ... but also easier, I'll
> go with that. I really dig the way that the tag attributes have a corresponding
It's a bit easier to read, and follows the same patterns as ant ( well,
almost :-). That should mean less things to learn.
Well, the whole thing about adding new tomcat modules is very similar
with adding new ant tasks, just replace <taskdef> with <module>. The big
difference is that instead of one method used by ant ( execute ), tomcat
has about 20 places a module can hook into.
> Yeah, that makes more sense. I was confused by the RequestInterceptor business,
> primarily because I couldn't see how to hook into the process without mimicking
> the current https RequestInterceptor. My module's lifecycle is complete once
> the user types in the password and hits ENTER, so leaving it sitting there in
> the middle of the request/response chain seemed weird. I now see how I can be a
> load-time module without being a connector.
Well, the other "fun" part is that we do introspection on each module to
detect what methods it overrides. So you can have as many "config" modules
as you want, each chain has only the modules that matter.
Of course, you can remove the module from the chains in addInterceptor
( just get the Hooks object and removed it ), or you can override
registerHooks and not have it registered in any hook chain.
Costin
