You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Serle Shuman <se...@creator.co.za> on 2000/03/23 18:16:16 UTC

Interceptor like components at the servlet context level

I suggest that the Interceptor concept i.e preService, postService calling
around requests be implemented in a similar manner around servlet context
loading. This will allow the loading and unloading of application wide
resources e.g. connection pools to be loaded into a context at startup and
unloaded at shutdown.

Is this a valid request?




Re: Interceptor like components at the servlet context level

Posted by Costin Manolache <co...@eng.sun.com>.
Serle Shuman wrote:

> Thanks Costin,
>
> Just need a bit more help, How would I go about installing my own
> ContextInterceptor. In the tomcat.xml file the ContextManager contains three
> request interceptors, 2 adapters, and three contexts. What tags would I use
> to define a contextinterceptor as opposed to a requestinterceptor. This

Use <contextinterceptor> tag for CI.
( It's a mistake, I should have used <interceptor> and decide based on
implemented interface - probably in next release all interceptors tags will have
the same effect)




> approach itself is probably wrong because I would actually need to define
> these properties in the deployment descriptor as I would need a specialised
> contextinterceptor per context/webapplication.

No, that is not posssible !!!
Web.xml is standard and should work with any servlet container, while
interceptors are tomcat specific.

You can set up your interceptor to operate only on specific contexts ( or
anything else ).

In next tomcat I'll fix the code so you can declare per-context interceptors, I
don't think I wrote the code to implement that yet, but it's very simple. (
still you need to use server.xml - no way to change the deployment descriptor ).

One idea would be to add a config file in the webapps.
It will work this way:
- all .jar and directories in webapps/ will be loaded as contexts with default
properties.
- all .xml files in webapps/ will be loaded as server.xml fragments declaring
contexts with non-standard properties or different docbase.

Costin

>
> Serle
>
> ----- Original Message -----
> From: Costin Manolache <co...@eng.sun.com>
> To: <ge...@jakarta.apache.org>
> Sent: Thursday, March 23, 2000 7:27 PM
> Subject: Re: Interceptor like components at the servlet context level
>
> >
> >
> > Serle Shuman wrote:
> >
> > > I suggest that the Interceptor concept i.e preService, postService
> calling
> > > around requests be implemented in a similar manner around servlet
> context
> > > loading. This will allow the loading and unloading of application wide
> > > resources e.g. connection pools to be loaded into a context at startup
> and
> > > unloaded at shutdown.
> > >
> > > Is this a valid request?
> >
> > You can do it right now using ContextInterceptor - it should have all the
> > methods you need ( you are notified when the context is added/removed ).
> >
> > If you need more - pre/post for example - it's a valid request, but can't
> be
> > done before the release ( we are just fixing bugs !).
> >
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org


Re: Interceptor like components at the servlet context level

Posted by Serle Shuman <se...@creator.co.za>.
Thanks Costin,

Just need a bit more help, How would I go about installing my own
ContextInterceptor. In the tomcat.xml file the ContextManager contains three
request interceptors, 2 adapters, and three contexts. What tags would I use
to define a contextinterceptor as opposed to a requestinterceptor. This
approach itself is probably wrong because I would actually need to define
these properties in the deployment descriptor as I would need a specialised
contextinterceptor per context/webapplication.

Serle

----- Original Message -----
From: Costin Manolache <co...@eng.sun.com>
To: <ge...@jakarta.apache.org>
Sent: Thursday, March 23, 2000 7:27 PM
Subject: Re: Interceptor like components at the servlet context level


>
>
> Serle Shuman wrote:
>
> > I suggest that the Interceptor concept i.e preService, postService
calling
> > around requests be implemented in a similar manner around servlet
context
> > loading. This will allow the loading and unloading of application wide
> > resources e.g. connection pools to be loaded into a context at startup
and
> > unloaded at shutdown.
> >
> > Is this a valid request?
>
> You can do it right now using ContextInterceptor - it should have all the
> methods you need ( you are notified when the context is added/removed ).
>
> If you need more - pre/post for example - it's a valid request, but can't
be
> done before the release ( we are just fixing bugs !).
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>


Re: Interceptor like components at the servlet context level

Posted by Costin Manolache <co...@eng.sun.com>.

Serle Shuman wrote:

> I suggest that the Interceptor concept i.e preService, postService calling
> around requests be implemented in a similar manner around servlet context
> loading. This will allow the loading and unloading of application wide
> resources e.g. connection pools to be loaded into a context at startup and
> unloaded at shutdown.
>
> Is this a valid request?

You can do it right now using ContextInterceptor - it should have all the
methods you need ( you are notified when the context is added/removed ).

If you need more - pre/post for example - it's a valid request, but can't be
done before the release ( we are just fixing bugs !).

Costin