You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Peter Donald <do...@apache.org> on 2001/01/19 01:09:54 UTC
RE: Interceptors
Hi,
At 12:29 19/1/01 +0100, Paulo Gaspar wrote:
>> -----Original Message-----
>> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
>> Sent: Thursday, January 18, 2001 23:04
>>
>> One appropriate question to ask yourself, when comparing, is
>> "what does having 15
>> entry points give me that I cannot get with a single entry point
>> approach"? If
>> there is nothing significant, then it would seem cleaner to rely on a
>> simpler-to-understand approach.
>
>That is a problem also found in several parts of business application
>frameworks - those things that help you building a big User Interface
>to manipulate and extract information from a big Database.
>
>You also find the same questions over GUI Frameworks - like Delphi's
>VCL or Java's Swing. And in database interface libraries...
>
>In all of these you find events (Hooks) named "onThis", "beforeThat"
>and "afterSomethingElse". And all this frameworks are built using
>Object Oriented Programming Techniques.
I think you are mixing concerns here. I have worked with multi entry point
interceptors (what you call hooks) before and I *believe* that there are
different levels of organisation that have to be examined. You mention GUIs
here so I will address them here. For instance consider javas GUI awt.
Under windows it gets it's events from a multitude of different sources
(some are grabbed from eventqueue, others from win32 hooks and others are
application created) then routes them through a central message queue and
central dispatching model. In many ways the way it works is similar to
hardwired valve style implementation. It is only at the upper layers where
it is transformed into the
preReleaseMouseButtonEventHookLudicrouselySizedMethod() and equivelent
postRelease*().
I agree that it is sooooooo much easier on the developer to do things this
way in the common approach. It becomes difficult in *certain* circumstances
but in most cases it is easier.
You will see that moderately complex hand-crafted GUIs also move in this
direction by routing them via a central bus and dispatching them in a more
friendly way higher up in the framework.
The advantage of hooks is also the speed of development - ie it takes about
1/5 of the time to develope a hook based solution rather than a general
solution. The general solution first has to be general and then it has to
layer specificity on top of that (see below) which is even more work.
>The advantage of Hooks is that the programmer is only exposed to the
>very narrow complexity of a very specific event. The framework takes
>care of the rest.
Right but generally the good frameworks go
specificity -> general -> specificty
So your GUI events functionality is provided by classes the extend the base
functionality in a OO way. In the case of Tomcat you would do it
differently - for hook "foo()" you would instead create a base valve
AbstractFooValve and repeat this for all valves. (Yes thats a damn lot of
work!!!)
>When you build your own thing that you put in a logic/data pipe,
>sometimes you have to understand a lot more about the inner working
>of the framework in order not to screw anything.
agreed. Thats why AbstractFooValve is near essential ;)
The only reason to choose Valves is for performance and flexability. You
pay for it in container dev time and initial dev complexity. But if you see
Tomcat4.x still being operational 2 years from release within a wide
variety of purposes then it is well worth it.
I am not saying that Catalinas concept of a valve is completely correct (it
uses the Anti-Pattern Subvertion of Control - yuck !!) but it is definetly
a step in the right direction. Personally if I was doing it then I would
implement Inversion of Control and your valve interface would be as simple
as below but I think Valves as they exist are a step forward thou YMMV.
public interface Valve {
public void invoke(ValveContext context, Request request, Response response)
throws IOException, ServletException;
}
public class MyValve implements Valve {
public void invoke(ValveContext context, Request request, Response response)
throws IOException, ServletException
{
...do stuff with request...
context.invokeNext( request, response );
...dostuff with response...
}
}
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
Re: Interceptors
Posted by Peter Donald <do...@apache.org>.
At 01:09 22/1/01 +0000, PSA wrote:
>> Under windows it gets it's events from a multitude of different sources
>> (some are grabbed from eventqueue, others from win32 hooks and others are
>> application created) then routes them through a central message queue and
>> central dispatching model. In many ways the way it works is similar to
>> hardwired valve style implementation. It is only at the upper layers where
>> it is transformed into the
>> preReleaseMouseButtonEventHookLudicrouselySizedMethod() and equivelent
>> postRelease*().
>
>Asynchronous messaging seems to be a very different animal to me than
>the very synchronous execution model of the valve system as implemented
>in catalina. Messaging guarantees event delivery and order of
>delivery. It disconnects the cause and effect processes -- sometimes at
>the expense of speed.
But in most windows systems except for a few the appearance of
"Asynchronous messaging" is just a simplification to help the developer
because it is really just synchronous. X, Win32, old MAC all go from
syn->async apearance
>> The advantage of hooks is also the speed of development - ie it takes about
>> 1/5 of the time to develope a hook based solution rather than a general
>> solution. The general solution first has to be general and then it has to
>> layer specificity on top of that (see below) which is even more work.
>
>This seems backward to me. Abstraction shouldn't be carried farther
>than it needs to go. The system is built in modular form, but that form
>still has a very specific task. There are levels of modularity in OOD.
>What is too specific to be allowed outside the application is necessary
>internally. And what is too specific application wide is necessary
>inside a module. Specificity of function is as much a part of OOD as
>abstraction.
I am not sure what you mean. It is standard that the more you invest in
something the more it pays of in long run. Certain OO practices decrease
initial build time but SOC and IOC are not such practices ;) Thou both pay
off in long run.
>> >The advantage of Hooks is that the programmer is only exposed to the
>> >very narrow complexity of a very specific event. The framework takes
>> >care of the rest.
>>
>> Right but generally the good frameworks go
>> specificity -> general -> specificty
>
>This seems to describe TC3-HEAD, with the general interface for modules
>being plugged (as interceptors) into specific parts of the
>request/response processing.
Right. But unfortunately due to limitations of java (ie check for NULL ptr
before calling method) is not possible. Which is why that high levels of
differentiation is beneficial to speed in java.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: Interceptors
Posted by Paulo Gaspar <pa...@krankikom.de>.
Damn, that is somethink I would like very much to see.
Many people indent HTML with spaces - those who code by hand.
Some of them (size conscious) unindent them for production
and sometimes partially indent again for fixing something!
And we often use "font" tags everywhere because of browsers
with bad CSS support.
I would feel much better about those spaces and font tags
thinking how little they would weight after gziped.
Ok! I know that all HTML (with all those repetitive tags)
benefits a lot from compression. But for me (and those HTML
coders) there is a feel good factor on gzip support.
=;o)
Have fun,
Paulo
> -----Original Message-----
> From: Remy Maucherat [mailto:remy@betaversion.org]
> Sent: Friday, January 19, 2001 23:10
>
> ...
>
> BTW, I think compression should be part of the HTTP connector.
> Every modern
> browser out there sends accept-encoding headers with the
> appropriate value :
> - IE 5 sends : gzip, deflate
> - Mozilla sends : gzip,deflate,compress,identity
> - Netscape 4.7 sends : gzip
> So roughly 95% of the requests will be wrapped by a compression
> valve. I also
> think that compression should be considered basic functionality.
>
> ...
>
> Remy
Re: Interceptors
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting "Craig R. McClanahan" <Cr...@eng.sun.com>:
> You would still need to wrap the response, for example, if your Valve
> wanted to
> modify the data content of the response (such as applying compression,
> or an XSLT
> transformation).
Ok.
BTW, I think compression should be part of the HTTP connector. Every modern
browser out there sends accept-encoding headers with the appropriate value :
- IE 5 sends : gzip, deflate
- Mozilla sends : gzip,deflate,compress,identity
- Netscape 4.7 sends : gzip
So roughly 95% of the requests will be wrapped by a compression valve. I also
think that compression should be considered basic functionality.
> However, you should choose to implement functionality
> like this
> as a Filter if you can, for maximum portability, and reserve Valve
> implementations for implementing internal-to-Tomcat functionality.
Makes a lot of sense.
Remy
Re: Interceptors
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
> Quoting Jon Stevens <jo...@latchkey.com>:
>
> > on 1/19/01 11:51 AM, "Craig R. McClanahan"
> > <Cr...@eng.sun.com>
> > wrote:
> >
> > > Agreed ... I'm talking about the *Apache Tomcat* release cycle, where
> > we
> > > agreed in the release plan to have a feature freeze / bug fix round on
> > 4.0,
> > > and work towards a production quality release quickly. API surgery is
> > not
> > > something normally done late in a cycle like this. That is why it
> > needs to be
> > > discussed (and voted on, IMHO) before we change what was previously
> > agreed to
> > > on TOMCAT-DEV.
> >
> > I thought that this is what we are discussing right now. :-) I'm +1 on
> > doing
> > API surgery at this point...
>
> Ok, I've thought about the issue, and I don't really like the change from
> Valves to Filters, because I have the following concerns :
> - Valves are internal. They access internal objects. Making them filters will
> lead to more typecasting and more rtti.
As you will see from the proposal, I'm not suggesting we actually use filters.
In particular, the request and response objects passed to Valves are the internal
ones (org.apache.catalina.Request / org.apache.catalina.Response) to maintain
access to the internals.
As you note, Valves are for internal things and Filters are for application
things. The proposal is to make the two APIs structurally similar, but still
recognize the differences.
>
> - I'd like a clarification on how much response and request wrapping would
> occur. Basically, all internal filters should be able to mutate freely either
> the request object or the response object by typecasting the request and the
> response. I don't see anything preventing this if we're inside the servlet
> container (except what the servlet API says).
>
The arguments to Valve.invoke() are still the internal request and response
objects, just as they are today.
Although I didn't mention it earlier, the Filter API allows for wrapping request
and response objects (such as when a servlet uses them in a RequestDispatcher).
The current Valve implementation already supports wrapping in a very similar
manner, although in practice it will not be needed often - because a Valve can
mutate the request and response objects to some degree, while a Filter cannot.
You would still need to wrap the response, for example, if your Valve wanted to
modify the data content of the response (such as applying compression, or an XSLT
transformation). However, you should choose to implement functionality like this
as a Filter if you can, for maximum portability, and reserve Valve
implementations for implementing internal-to-Tomcat functionality.
>
> Do you think either of these is justified ?
>
> Remy
>
Craig
Re: Interceptors
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting Jon Stevens <jo...@latchkey.com>:
> on 1/19/01 11:51 AM, "Craig R. McClanahan"
> <Cr...@eng.sun.com>
> wrote:
>
> > Agreed ... I'm talking about the *Apache Tomcat* release cycle, where
> we
> > agreed in the release plan to have a feature freeze / bug fix round on
> 4.0,
> > and work towards a production quality release quickly. API surgery is
> not
> > something normally done late in a cycle like this. That is why it
> needs to be
> > discussed (and voted on, IMHO) before we change what was previously
> agreed to
> > on TOMCAT-DEV.
>
> I thought that this is what we are discussing right now. :-) I'm +1 on
> doing
> API surgery at this point...
Ok, I've thought about the issue, and I don't really like the change from
Valves to Filters, because I have the following concerns :
- Valves are internal. They access internal objects. Making them filters will
lead to more typecasting and more rtti.
- I'd like a clarification on how much response and request wrapping would
occur. Basically, all internal filters should be able to mutate freely either
the request object or the response object by typecasting the request and the
response. I don't see anything preventing this if we're inside the servlet
container (except what the servlet API says).
Do you think either of these is justified ?
Remy
Re: Interceptors
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/19/01 11:51 AM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we
> agreed in the release plan to have a feature freeze / bug fix round on 4.0,
> and work towards a production quality release quickly. API surgery is not
> something normally done late in a cycle like this. That is why it needs to be
> discussed (and voted on, IMHO) before we change what was previously agreed to
> on TOMCAT-DEV.
I thought that this is what we are discussing right now. :-) I'm +1 on doing
API surgery at this point...especially given that you are doing development
towards a release of Tomcat 4.x based on a Servlet API version that isn't
release either. :-) What if the Servlet API changes tomorrow? That would be
more API surgery as well IMHO. Also, given that this would be surgery
towards making things more compatible with the Servlet API, I think that it
is more than justified. :-)
-jon
Re: Interceptors
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:
> on 1/19/01 9:38 AM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > Impact on the overall
> > 4.0 release cycle is more problematic -- I think we would want to do this in a
> > new
> > beta round and add a week of intensive testing to make sure nothing got
> > destabilized.
>
> Remember that Sun does not control the 4.0 release cycle.
>
Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we agreed in
the release plan to have a feature freeze / bug fix round on 4.0, and work towards a
production quality release quickly. API surgery is not something normally done late
in a cycle like this. That is why it needs to be discussed (and voted on, IMHO)
before we change what was previously agreed to on TOMCAT-DEV.
>
> -jon
>
Craig
Re: Interceptors
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/19/01 9:38 AM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> Impact on the overall
> 4.0 release cycle is more problematic -- I think we would want to do this in a
> new
> beta round and add a week of intensive testing to make sure nothing got
> destabilized.
Remember that Sun does not control the 4.0 release cycle.
-jon
Re: Interceptors
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:
> on 1/18/01 4:28 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > If you change the names and parameter orders a little, you have just quoted
> > the
> > new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
> >
> > I'd be game to change the Valve APIs to conform to this kind of pattern in a
> > 4.1
> > timeframe, if people prefer it. If we're ever going to do this, earlier is
> > better
> > (before too many valves that have to be changed get created).
>
> I'm almost thinking that this should be done for 4.0 because 4.0 is going to
> be implementing the 2.3 spec and having two different filtering mechanism's
> doing essentially the same thing doesn't make much sense to me...
>
I can sympathize with that concern -- I really really don't want to go changing
fundamental APIs in dot releases the way that 3.x has.
>
> Note, I'm not volunteering to scratch this itch...I'm just giving an
> opinion.
>
Thanks a bunch :-)
>
> Craig, can you make a statement about how hard/timeframe it would be to make
> the two different filtering mechanism's match up?
>
Effort requirements are probably 4-6 hours for development and execution for
changing the implementation plus all the existing valves. Impact on the overall
4.0 release cycle is more problematic -- I think we would want to do this in a new
beta round and add a week of intensive testing to make sure nothing got
destabilized.
Let me work up a specific proposal (with impact estimates) and I propose it later
today. There will also be a different proposal (based on input from Glenn) for a
"facade" layer that will make it easier to do the security manager stuff -- I
would want to do both sets of changes together if we're going to do them.
>
> thanks,
>
> -jon
>
Craig
RE: Interceptors
Posted by Paulo Gaspar <pa...@krankikom.de>.
As a "piping" mechanism (as opposed to a "hooking" one) the kind
of thing Donald described is my favorite one.
My other $0.02 are that I agree 100% with Jon on this. People will
get confused if you have 2 different ways of using valves from a
minor version to the other.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Friday, January 19, 2001 02:22
>
> on 1/18/01 4:28 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > If you change the names and parameter orders a little, you have
> just quoted
> > the
> > new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
> >
> > I'd be game to change the Valve APIs to conform to this kind of
> pattern in a
> > 4.1
> > timeframe, if people prefer it. If we're ever going to do
> this, earlier is
> > better
> > (before too many valves that have to be changed get created).
>
> I'm almost thinking that this should be done for 4.0 because 4.0
> is going to
> be implementing the 2.3 spec and having two different filtering
> mechanism's
> doing essentially the same thing doesn't make much sense to me...
>
> -jon
Re: Interceptors
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/18/01 4:28 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> If you change the names and parameter orders a little, you have just quoted
> the
> new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
>
> I'd be game to change the Valve APIs to conform to this kind of pattern in a
> 4.1
> timeframe, if people prefer it. If we're ever going to do this, earlier is
> better
> (before too many valves that have to be changed get created).
I'm almost thinking that this should be done for 4.0 because 4.0 is going to
be implementing the 2.3 spec and having two different filtering mechanism's
doing essentially the same thing doesn't make much sense to me...
Note, I'm not volunteering to scratch this itch...I'm just giving an
opinion.
Craig, can you make a statement about how hard/timeframe it would be to make
the two different filtering mechanism's match up?
thanks,
-jon
Re: Interceptors
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Peter Donald wrote:
> [snip]
> I am not saying that Catalinas concept of a valve is completely correct (it
> uses the Anti-Pattern Subvertion of Control - yuck !!) but it is definetly
> a step in the right direction. Personally if I was doing it then I would
> implement Inversion of Control and your valve interface would be as simple
> as below but I think Valves as they exist are a step forward thou YMMV.
>
> public interface Valve {
> public void invoke(ValveContext context, Request request, Response response)
> throws IOException, ServletException;
> }
>
> public class MyValve implements Valve {
> public void invoke(ValveContext context, Request request, Response response)
> throws IOException, ServletException
> {
> ...do stuff with request...
> context.invokeNext( request, response );
> ...dostuff with response...
> }
> }
>
If you change the names and parameter orders a little, you have just quoted the
new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
I'd be game to change the Valve APIs to conform to this kind of pattern in a 4.1
timeframe, if people prefer it. If we're ever going to do this, earlier is better
(before too many valves that have to be changed get created).
>
> Cheers,
>
> Pete
>
Craig
Re: Interceptors
Posted by PSA <po...@posom.com>.
I haven't posted here before, but I do follow the list closely, as well
as the code and the development efforts and have posted in the past on
other apache boards. I'm
hoping to get involved more directly with development issues (and bugs)
as we
prepare to move our application to TC3.x(where x>2).
As this particular discussion is of special interest I hope you don't
mind another voice.
See below.
Peter Donald wrote:
> >> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> >> One appropriate question to ask yourself, when comparing, is
> >> "what does having 15
> >> entry points give me that I cannot get with a single entry point
> >> approach"? If
> >> there is nothing significant, then it would seem cleaner to rely on a
> >> simpler-to-understand approach.
> >
> >That is a problem also found in several parts of business application
> >frameworks - those things that help you building a big User Interface
> >to manipulate and extract information from a big Database.
> >
> >You also find the same questions over GUI Frameworks - like Delphi's
> >VCL or Java's Swing. And in database interface libraries...
> >
> >In all of these you find events (Hooks) named "onThis", "beforeThat"
> >and "afterSomethingElse". And all this frameworks are built using
> >Object Oriented Programming Techniques.
>
> I think you are mixing concerns here. I have worked with multi entry point
> interceptors (what you call hooks) before and I *believe* that there are
> different levels of organisation that have to be examined. You mention GUIs
> here so I will address them here. For instance consider javas GUI awt.
>
> Under windows it gets it's events from a multitude of different sources
> (some are grabbed from eventqueue, others from win32 hooks and others are
> application created) then routes them through a central message queue and
> central dispatching model. In many ways the way it works is similar to
> hardwired valve style implementation. It is only at the upper layers where
> it is transformed into the
> preReleaseMouseButtonEventHookLudicrouselySizedMethod() and equivelent
> postRelease*().
Asynchronous messaging seems to be a very different animal to me than
the very synchronous execution model of the valve system as implemented
in catalina. Messaging guarantees event delivery and order of
delivery. It disconnects the cause and effect processes -- sometimes at
the expense of speed.
> The advantage of hooks is also the speed of development - ie it takes about
> 1/5 of the time to develope a hook based solution rather than a general
> solution. The general solution first has to be general and then it has to
> layer specificity on top of that (see below) which is even more work.
This seems backward to me. Abstraction shouldn't be carried farther
than it needs to go. The system is built in modular form, but that form
still has a very specific task. There are levels of modularity in OOD.
What is too specific to be allowed outside the application is necessary
internally. And what is too specific application wide is necessary
inside a module. Specificity of function is as much a part of OOD as
abstraction.
> >The advantage of Hooks is that the programmer is only exposed to the
> >very narrow complexity of a very specific event. The framework takes
> >care of the rest.
>
> Right but generally the good frameworks go
> specificity -> general -> specificty
This seems to describe TC3-HEAD, with the general interface for modules
being plugged (as interceptors) into specific parts of the
request/response processing.
I agree completely with the rest of your message, but, of course, those
changes have already been proposed at the time of my writing.
As always, I am open to instruction.
Thanks for helping me understand these issues better.
-Paul
RE: Interceptors
Posted by Paulo Gaspar <pa...@krankikom.de>.
Over the weekend I will start having a look at 3.x HEAD. If you do not
think that document is urgent and no one faster at doing it pops up, I
can try writing something like that.
Have fun,
Paulo Gaspar
P.S.: BTW, I was also refering to specialized events has in Swing. That
is the kind of thing that realy cuts down development complexity.
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Friday, January 19, 2001 05:54
>
> P.S. Those are just few of the reasons behind the 3.x Interceptors. It
> would be great if someone would want to help creating a small document
> based on the discussions we had - with the pros and cons. I could also add
> few examples, and maybe go into more details about how the most
> important
> chains work ( Error handling, session, auth, mapping )
>
RE: Interceptors
Posted by cm...@yahoo.com.
Hi Pete,
My goal is to explain why and how interceptors are used in
tomcat3.x. While other solution exist,
the design of tomcat3.x is based on certain design patterns that have
certain advantages ( and disadvantages).
The reasons for choosing this pattern:
1. One of the goals is to integrate with web servers.
Using similar design patterns with those used in all major servers is
supposed to simplify this and make possible special optimization. A
different pattern would create an impedance mismatch.
2. This model is well tested in production web servers.
3. Apache evolution is a very important lesson. The direction is clear in
introducting more hooks - and the benefits are highly visible in
Apache 2.0 where amazing modularization happened ( MPM, http as a module,
etc).
4. Reusing the existing patterns should make easier for people to develop
modules - the skills for building IIS filters or Apache modules are
similar with those for building tomcat modules.
5. During tomcat evolution from 3.0 to (proposed) 3.3, adding more hooks
proved to greatly simplify the code and improve performance.
6. Performance. We'll have much shorter and specialized chains, and only
the hooks that are needed will be called. For example, it may not be
needed to call the authenticate method if the request doesn't need that
( even if the request includes authentication info ).
7. Scalability (!). When you have 10 modules, life is simple. When you
have almost 50 - things are different. Apache has much more, and in 2
years we may also get quite a few.
The question is - is it better to fit everything in one hook or to have
specialized chains ?
I would like to mention that both models are possible in tomcat 3.x -
by implementing the Handler and extending invoke() you can support the
same programming model.
It is interesting to note that all servers are also making a distinction
between content generators/filters ( that are implemented in the Handlers
- using the invoke() chain ), and SAFs/hooks/request filters that are
specialized processing chains for various server functions ( auth,
mapping, etc).
As another note - someone mentioned AWT and the event model in windows (
where all events treated uniformly and dispatched by an event queue ).
In this analogy, Tomcat3.x is more using the swing model, of specialized
listeners closelt coupled with the event generators.
As a matter of fact, early in tomcat3.2 development I tried to use
Event/Listeners model - but didn't go forward because of the object
allocation was too hard to control. The pattern is the same, just the
implementation as Interceptor is slightly more efficient.
Costin
P.S. Those are just few of the reasons behind the 3.x Interceptors. It
would be great if someone would want to help creating a small document
based on the discussions we had - with the pros and cons. I could also add
few examples, and maybe go into more details about how the most important
chains work ( Error handling, session, auth, mapping )