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 04:14:25 GMT

> 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).

You can modules in Perl too. And soon - I hope - you'll be able to
write modules in Java !

> And while it is also true that most of our initial deployments will
> ship with a standard Web server (most likely Apache) that may not
> always be the case.

Sure - but whatever design  should still be able to
address Apache integration and be useable in production sites -
real web servers with real high load.

Do you think the Realm interface with the 2 methods is the
right solution for authentication ?

What model for request processing do you prefer ?

My personal preference is to use Event and EventListeners -
they have a simpler design and resolve the same problem.
Maybe one day I'll just implement that as a revolution,
with a lot more care for GC.
But I'm not sure it is "better" - and I'll not be sure until
I have a prototype and I can compare it and see how it works
in real world.

Web servers have a long history and a lot of smart developers,
and this model seems to work - and it was more than used in
all those years. I need more than words to use something
out of whiteboards.

> So while I agree Tomcat will/shouldn't replace the everyday
> workhorse Web servers, there are areas where it likely will fill in
> where we cannot see (if you can, make sure you have access to
> some VC because you'll likely cash in big).

If we expect people to use servlets/jsp instead or in addition to
mod_perl/php/asp we should be able to run in similar conditions
with similar speed. If the response time is more than 2 seconds -
nobody cares that your software can also run from a toaster. If you can't
use the same authentication as the rest of your applications -
nobody cares that you have plugeable  APIs or original architecture.

If we discuss about how the request is processed - including authentication -
I'm interested to hear how much processing is part of the critical path,
how and what alghoritms and data structures can we use to implement
the parsing and searching, and how can we reuse existing code.

If we discuss about authentication - I'm interested how can we address
existing systems ( like apache + any auth module). In a controled
environment everything works fine and looks flexible.


View raw message