You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cm...@yahoo.com on 2001/01/18 21:56:20 UTC
Interceptors ( was Re: 3.x vs 4.0 architecture Q's
> Looking at the latest 3.x src drops, there are say ~30 methods in
> BaseInterceptor, that is access points, into the request chain / context
> mapping / session handling etc. This obviously gives a degree of
Hi Ken,
All this will be reviewed and documented - if the release proposal is
accepted. I would really like to have the 3.x Interceptors discussed in
detail and any sugestion incorporated ( before the proposed beta).
> control/access to the internals, though does raise the question, how many
> are enough? Are those enough because they now cover all the functionality a
> server does? Or will a few extra be needed as time goes on? This seems a
Apache 1.3 needs about 15, and was able to do everything it does using
only those.
Apache 2.0 provides a mechanism to add more - the so-called HOOKS.
The current tomcat 3.x hooks need to be reviewed to make sure we have all
we need. I wouldn't mind adding few more ( before beta ), or removing any
that reviewers feel is not needed.
> bit brittle to me. If an extra method is added, presumably that means a new
> hook into an internal api, and the code to support it. Does this mean
> multiple interfaces / base classes are required? All pluggable? What about
> the existing interceptors people have written? It would be really good to
> hear an argument for this design? What are the benefits of it? Does it
> gives the server internals better control / optimisation opportunities?
Adding a method is backward-compatible, and in general doesn't require
recompilation for existing interceptors.
All of the tomcat3.x functions are now implemented in modules - so it's
not likely we'll need many more hooks. Given that all Apache 1.3
modules used only 15 ( or less ? ) means that we should be fine.
My experience was that adding a hook is greatly simplifying the code and
allows better organization. A good example is the handleError() hook that
allowed to turn all the (complex) error handling code in a module.
I had a (working) prototype implementing an extensible mechanism similar
with Apache2.0, but my belief is that it isn't needed in the context of
the proposed 3.3. ( it was developed early in 3.2 days, so it's now
out-of-date, but I can publish it if you want to take a look ).
> Costin's arcticle mentioned that the Handler/Wrapper classes actually allow
> 3.x to use valves -- is this a clean interface (I confess to not having got
> that far yet) ? As simple as 4.0? It also states that some of the current
> Interceptors were / could have been Valves, but but were chosen not to be,
> but does really explain why.
Handler has the invoke(), setNext, setPrevious methods similar with
Valve. I'll add more explanations in the documentation - after the whole
release plan issue is resovled. ( please remind me :-). The design patter
is the same ( chain of command), except that Interceptors provide multiple
chains.
The main reason for writing the current modules as Interceptors was
the fact that Apache modules are using the same model - and it was felt
that this will help with the integration ( "advanced" integration can be
greatly simplified by using the same model ).
Costin
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 )
RE: Interceptors
Posted by Peter Donald <do...@apache.org>.
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 ( was Re: 3.x vs 4.0 architecture Q's
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/18/01 2:03 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> IMHO, copying a web server (written in C, by the way) architecture, in and
> of itself, is not a compelling argument to influence the design of a servlet
> container written in an object oriented language like Java.
+1
-jon
RE: Interceptors ( was Re: 3.x vs 4.0 architecture Q's
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----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.
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.
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.
So, it is not as straightforward as you put it. It is a case by case
thing.
> Also, IMHO, copying a web server (written in C, by the way)
> architecture, in and
> of itself, is not a compelling argument to influence the design
> of a servlet
> container written in an object oriented language like Java. The
> question is
> really "what's in it for Tomcat?".
Apache is not a complete model for building Tomcat, but provides some
interesting ideas one can learn from. The small core general idea is
a classic in flexible systems, but the focus here is on the hooks.
Apache gives a tested answer to the question of which hooks are enough.
Re: Interceptors ( was Re: 3.x vs 4.0 architecture Q's
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com wrote:
> > Looking at the latest 3.x src drops, there are say ~30 methods in
> > BaseInterceptor, that is access points, into the request chain / context
> > mapping / session handling etc. This obviously gives a degree of
>
> Hi Ken,
>
> All this will be reviewed and documented - if the release proposal is
> accepted. I would really like to have the 3.x Interceptors discussed in
> detail and any sugestion incorporated ( before the proposed beta).
>
> > control/access to the internals, though does raise the question, how many
> > are enough? Are those enough because they now cover all the functionality a
> > server does? Or will a few extra be needed as time goes on? This seems a
>
> Apache 1.3 needs about 15, and was able to do everything it does using
> only those.
>
> Apache 2.0 provides a mechanism to add more - the so-called HOOKS.
>
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.
Also, IMHO, copying a web server (written in C, by the way) architecture, in and
of itself, is not a compelling argument to influence the design of a servlet
container written in an object oriented language like Java. The question is
really "what's in it for Tomcat?".
Craig McClanahan