tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 18:25:00 GMT
"Craig R. McClanahan" wrote:

> Costin Manolache wrote:
> > > I know about Perl (that's the day job ;) and Apache. There's also a
> > > simplistic Perl api for Netscape and I think you can do something
> > > in IIS, but the point is that even with Perl, the underlying
> > > architecture is still primarily derived because the server itself is in C.
> >
> > I'm curious - where do you think is the impact of C in this architecture?
> > My impresion is that what matter most is the alghoritm - not the
> > language you use to express it.
> >
> It matters because design patterns copied from C sometimes have performance
> impacts when you transliterate them to Java.

I would argue that "design patterns" are language independent - in this particular
case it's probably a "Chain of Responsability" pattern, with a bit of "Strategy".
Implementation of those strategies in C and Java may differ - but still there is
not C that is the reason for this pattern !

Apache 2.0 is even closer to those patterns ( with hooks ).

> Consider the current RequestInterceptor interface, with roughly 10 "handler"
> methods.  In C, it is pretty low overhead to maintain a dispatch table of
> pointers to functions, and just call the ones that are non-NULL (i.e. the ones
> that the module has registered itself as interested in).  In Java, all 10 of
> those calls happen on *every* interceptor (assuming they flow on through, which
> is the usual case), on *every* request.  Most of them just use the empty
> impelmentation in the default base class -- they are relatively cheap, but they
> are definitely NOT free.

As I said earlier - the RequestInterceptor _interface_ is fine - it provides
getMethod() that should return the  "chains of responsibility" the interceptor
is interested in, and only those methods will be included in the dispatch
table for that particular event.

The implementation is not done - it was better to spend time in other areas, and
the impact of not having that implemented is not bad. The design is fine.

There is a problem with the current interceptor - the fact that it's hard to
extend it ( you have to add a new method ) - but that's a choice that I still think

 was right. The main reason for that was to keep a familiar and simple interface.
The alternative is to do something like the hooks in apache - but I felt
that for now it's better to keep it simpler. There is no problem implementing
_both_  - the behavior is the same and the 2 concepts are inter-changeable,
but I would rather wait with that till it's really needed.

( in fact my hope is to combine hooks with another very important java-only
implementation - CharBuffers, to reduce the String GC. If we do that it will
make sense to do this big step). Java is great because we can support multiple
implementations of the pattern and provide backward compatibility - which
is harder on C.

> In comparison, the Catalina architecture for Valves requires one method call per
> interceptor -- to the invoke() method -- no matter how complex its internel
> logic is.  There are other differences that I want to address in the context of
> a response to one of Gal's questions; this will be in a separate message.

As I explained - it is possible to have one call per interceptor if there is only
one interceptor ( from  Strategy point of view) for that operation.

On the other side - Valve implements a completely different alghoritm and pattern-
it divides the problem into smaller problems. I.e.

processing a request == extract the context + process context mapping.

One Valve will implement the first step, and a second one will split "process
ctx mapping" in "extract servlet path + call servlet wrapper  container".

There are a lot of fundamental problems with this - one is that it
impose a certain parsing/matching alghoritm that is not the most
efficient.  What's worse - it does this at the object-model level.
Another big problem - from all the web-server experience, it
seems Chain of Responsability _is_ important - it allows use
of different althoritms and more flexibility.

Authentication is just one particular case of this...


View raw message