tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Clarke" <>
Subject Re: request for review: server/config discussion
Date Wed, 21 Jul 1999 03:03:53 GMT
How about we get a really good JSP/Servlet engine for V1 and go for a fully
abstracted configuration architecture in V2?

What does it really buy us, apart from a really cool design? (Don't get me
wrong a properly abstracted configuration mechanism would be great - but if
I can configure it at all that's good enough for me)

The main issue with a basic config file strategy that I can see is that it
should be a requirement to have multiple engines in a cluster running of the
same configuration file. Weblogic does this with basic configuration files
(it has one server which provides config information to the rest I think).


Tom Clarke
Senior Software Engineer
v 212.358.2798
----- Original Message -----
From: Troy Poppe <>
To: <>
Sent: Tuesday, July 20, 1999 10:53 PM
Subject: Re: request for review: server/config discussion

> On Tue, Jul 20, 1999 at 07:44:39PM -0700, James Todd wrote:
> > i see a couple of dimensions unfolding here and, while i prefer
> > to keep things simple in the early stages so that we can start
> > proto-typing some of the these concepts, we should still strive
> > to aim high, a possible target being:
> >
> > if the "config service" supports http as one communication
> > protocol (lots of good reasons to do this)
> >
> > it will need to rely on an http server (or embedded
> > server)
> Is there such a thing as an infinite loop in design? ;)
> This definately could be an option, and I agree, Tomcat would
> fit the bill well.  However, I think we need to generalize this
> more, being careful not to err on the side of over-generalizing.
> I'm seeing the configuration API as nothing more than a stub
> for any number of configuration/persistance options.
> I don't see why we couldn't do something similar to the JCE/JCA
> from Sun.  In this architecture/implementation, you have the
> ability to write your own 'providers' for encryption algorithms.
> Now, this type of architecture could apply closely to configuration
> IMO.
> Imagine the following scenarios:
> - Configuration from LDAP or other directory service via JNDI
> - Configuration via an HTTP server
> - Configuration from a flat file
> - Configuration from a database
> Then to add to the complexity of these scenarios, toss in the flavor
> of XML or your choice, DTDs, XSchema, etc.  I like the idea of all
> of these, but I also understand that some organizations may not want
> to bring their configurations from a flat file, or LDAP for that matter.
> If the API is simple, and we allow others to extend it to do whatever,
> I think we're really going to build something rather powerful.
> My $.01 (is it work $.02?).
> - Troy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message