tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 18:07:43 GMT
Shachor Gal wrote:

> <snip>
> >
> > I'm all for discussion. After all this is rather groundbreaking stuff.
> > While 'tis true that all of the popular Web servers use a filter model
> > similar to our interceptor model, they also all use C to write their
> > servers. (IIS may use C++, but if it follows MS tradition that is just
> > C++ wrappers around straight C code like the Windows API).
> >
>
> I am not saying "... Web server X does that, so we must blindly do it
> to ...", my point is that most web servers selected the interceptor model
> and it was not the programming language that forced them to select it (You
> can wrap objects within other object in almost any language). We should
> not just forget this.
>
> Note, I am not saying that we should go with "strict" interceptor model,
> only that I need to have a good reason to abandon it in favor of wrappers.
>

Gal, I'm assuming that by "wrappers" you are referring to the Valve approach
in Catalina versus the RequestInterceptor approach in Tomcat 3.x -- is that
right?  If not, could you please help me understand what you're referring to
there.

On the assumption that this is what you mean, a quick comparison of Valves
versus RequestInterceptors is interesting.  The key similarities:

* They can both be configured and deployed at startup time.

* They both have access to other components -- principally the
  internal request and response instances, but also other things
  like the Context.

* They can both be used to implement "filter" (the request passes
  on through) or "handler" (the request is handled, and no further
  processing happens).  This latter capability of RequestInterceptors
  was not obvious in the code (lack of comments) to me earlier --
  I apologize for mis-stating this in an earlier email.

There are also some differences:

* State Management -- Both RequestInterceptors and Valves are
  used in a multithreaded environment (thread per concurrent
  request).  As a result, any state about this request that a
  RequestInterceptor wants to save must be stored in the request
  itself.  In a Valve, you can do that (important if some other
  component needs access to this information) but you can also
  use local variables inside the invoke() method for state information
  that is purely local to this request.

* Complexity -- RequestInterceptor provides you circa 10 entry points,
  and you must understand the request processing lifecycle in pretty
  good detail to know where your logic should go.  Valves are called
  once per request, so this is quite obvious.  See more on this topic
  below; there are other subtleties.

* Performance Overhead -- A RequestInterceptor that passes requests
  on (the usual case) receives circa 10 method calls per request, versus
  one for a Valve.  In addition, the requirement to store state information
  in the request, as opposed to on the stack, can cause additional
  overhead to implement the same functionality.

The key question, though, is "can I implement something using one approach
that I cannot implement in the other".  The only place I can see a big
difference here is the case where you want all of the interceptors to have a
crack at, say, the requestMap() call, then go back and call all of them again
for the authenticate() call.  (For those of you familiar with Apache modules,
that's the way they work).  While one could discuss how often you need that
kind of thing inside a servlet container (versus when writing webserver
extensions), it can be implemented when needed with Valves by simply having
more than one Valve in the pipeline, using shared state behind the scenes as
required to accomplish the functional purpose required.

Given equivalence in "functional power" (or whatever you want to call it), I
tend to go for simplicity (especially when it reduces overhead, as is true in
this case).

NOTE:  There are lots of other things to consider when looking at
Catalina-vs-Tomcat-3.x -- and those things will change in the future -- but
request interception is one of the places where the two approaches differ the
most, and it's worth comparing them in depth.

Craig McClanahan



Mime
View raw message