You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Serle Shuman <se...@creator.co.za> on 2000/03/27 10:27:12 UTC

ContextInterceptors & Interceptor configuration

I would like to be able to add and remove application wide components
(singletons per web app/context) on context startup and correspondingly on
context shutdown. This would allow all servlets running in the context to
retrieve handles to these singletons in the standard manner. If I understand
Costin correctly I should do this via the ContextInterceptor mechanism.
Having looked at the code I have observed:

The Context class has an addInitInterceptor(LifeCycleInterceptor li) and
addDestroyInterceptor(LifeCycleInterceptor li). Should these take a
ContextInterceptor or a LifeCycleInterceptor?

Moving on to the ContextManager, on context initialisation we need to add
code to getInitIntercepors and call the corresponding Intercepor methods,
likewise on context shutdown/destroy.

Next we need to be able to specify the Interceptor configurations. For
context interceptors, I think this should be in the web.xml file as it
represents all the other context configuration and we would need a list of
context interceptors. Likewise for serviceInterceptors this should be done
in the servlet definition DTD. Having added the Interceptor concept
(excellent), how are we being constrained by the fact that the configuration
DTD i.e. web.dtd is specified as part of the Sevlet 2.2 spec? therfore not
open to change.

I would like to contribute this functionality to the codebase, however I
would like to do it in the right manner.

Serle


Re: ContextInterceptors & Interceptor configuration

Posted by Costin Manolache <Co...@eng.sun.com>.
> I would like to be able to add and remove application wide components
> (singletons per web app/context) on context startup and correspondingly on
> context shutdown. This would allow all servlets running in the context to
> retrieve handles to these singletons in the standard manner. If I understand
> Costin correctly I should do this via the ContextInterceptor mechanism.
> Having looked at the code I have observed:
>
> The Context class has an addInitInterceptor(LifeCycleInterceptor li) and
> addDestroyInterceptor(LifeCycleInterceptor li). Should these take a
> ContextInterceptor or a LifeCycleInterceptor?

Both methods are deprecated.
Setting per-context interceptors is not implemented in 3.1 - it's easy to do
that, and most of the code is in, but I don't think anyone tested the code.
After this release - any contribution in this area is wellcome.

( LifeCycleInterceptor was used in J2EE integration, it's better to use the
ContextInterceptor instead )


> Moving on to the ContextManager, on context initialisation we need to add
> code to getInitIntercepors and call the corresponding Intercepor methods,
> likewise on context shutdown/destroy.

init/destroyInterceptor is no longer used - there are callbacks in
ContextInterceptor
that provide the same functionality ( and more )

> Next we need to be able to specify the Interceptor configurations. For
> context interceptors, I think this should be in the web.xml file as it
> represents all the other context configuration and we would need a list of
> context interceptors. Likewise for serviceInterceptors this should be done
> in the servlet definition DTD. Having added the Interceptor concept
> (excellent), how are we being constrained by the fact that the configuration
> DTD i.e. web.dtd is specified as part of the Sevlet 2.2 spec? therfore not
> open to change.

You can only use tomcat-specific config file, and your code will be tomcat
specific - I don't think the interceptors will be standardized very soon.
( at least we need to have some experience and more knowledge )


> I would like to contribute this functionality to the codebase, however I
> would like to do it in the right manner.

Take a look at ContextInterceptor interface - I think it's the right starting
point.

One very interesting idea is to use Event/Listener model - that will allow
us to generalize the interceptor model ( including the ability to add new
"events"
without changing existing interfaces ).

Costin