tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: Tomcat.Next Component Interfaces Checked In
Date Sun, 09 Jan 2000 18:00:39 GMT wrote:
> Assaf Arkin wrote:
> > I can think of several reasons why the interceptor would like to know
> > what container it's bound to, e.g. to find out what realm it's running,
> > or get the context configuration, etc.
> >
> > In that case only setInterceptor is required, not getInterceptor, and
> > will be called only once thrown an ILSE if called twice. The same design
> > pattern is also used in EJB with setSessionContext called on a Bean.
> Well, it's difference between "interceptor would like to know the
> container" and "interceptor _is required_ to know it".
> That method in the interface means ALL interceptors are REQUIRED
> to remember the container, and as a hidden effect means "an interceptor
> can be used ONLY for one container, you CAN'T have a singleton
> used by all containers, like a CountInterceptor"

That's precisely why I see getInterceptor as redundant.

> I would agree with a "setContainer" without "getContainer" ( or better
> "addContainer" ). My problem is with the "one-to-many" instead of
> "many-to-many" relationship ( which I don't think it good to REQUIRE,
> in EJB it is by design, I disagree with designing interceptors with
> one-to-many
> requirements).

I look at the Interceptor as an accessor into a larger system. If Tomcat
is running four containers, it will have four inteceptors with different
configuration talking to one Tyrex engine. Or it will have four logger
interceptors synchronizing access to the same file.

Your many-many relation is between the container and the back-end
through a one-many interceptor relationship.


> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message