tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 02:23:09 GMT
On 18 Apr 00, at 12:42, Craig R. McClanahan wrote:

> Shachor Gal wrote:
> > I think that this argument get a little out of proportion here...
> >
> > You are comparing two completely different things:
> > 1. A working servlet container (Tomcat)
> > 2. A design that (relative to the above) is mostly on the blackboard.
> >
> > And, you make the comparison based on a portion of Tomcat that is known
> > to be unfinished...
> >
> Hmm, unfinished versus incomplete ... sounds more similar than different :-)
I agree. After hacking on the interceptor all weekend, I'd say that 
we're definitely not something I would calll complete. ;)
> Seriously, you're absolutely right -- we need a functional implementation of
> Catalina in order to compare on anything other than theoretical grounds.  One
> of my motivations in bringing this up is to start comparing design approaches,
> and hopefully garner some interest in helping to create just such a functional
> implementation.
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). 

We are talking about Java here and we should be looking for a 
proper Java solution. Perhaps this still leaves us with an interceptor 
based solution. But maybe it doesn't. I mean we haven't even 
talked about using things like reflection and dynamic loading. 
We're doing it for servlets, why not Tomcat itself?

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.

Now that Mozilla is finishing up and we have something like 
Tomcat, this gives us a whole new set of tools to build new 
sophisticated Web applications that don't necessarily fit into our 
old patterns. For example perhaps you want to build a distributed 
database application for your sales force. You like the cool stuff 
Java brings in the form of JDBC, RMI, etc for doing distributed 
database development, but SWING programming sucks, in 
particular when compared to HTML. You could instead build the 
interface using XUL/Javascript and some CSS. Because Mozilla 
can switch skins easily you can build a suite of applications that 
look/act differently but use the same underlying technology.

Thus Mozilla becomes the front-end. You use a local server-side 
component to run the actual application. You don't really need 
Apache, when you simply need a servlet engine. Might as well use 

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

> >
> >     Gal Shachor
> Craig McClanahan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message