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:29:08 GMT
I came over ruthlessly pragmatic for a moment there ;-)

Seriously though, from a user/sysadmin perspective, does it actually buy you
anything - having multiple configurations I mean?

I can't think of an application that gives you this much flexibility in
configuration. Doesn't mean it's not valuable, but what are the scenarios it
gives me benefit as a user/sysadmin? (and doesn't just make it more
confusing and complicated)

Having said these things though:
    a) Going pie in the sky is _always_ a good idea in my experience, it
helps you find where the sky is and allows you to find the right compromise
between extremes.
    b) This is an open source project - if anyone thinks something is cool
and thinks its cool enough to devote time to, who am I to tell them
otherwise - it will ultimately benefit everyone.

One of the things that Weblogic allows you to do, is have configuration
specific to an individual server that overrides the global configuration.


Tom Clarke
Senior Software Engineer
v 212.358.2798
----- Original Message -----
From: James Todd <>
To: <>
Sent: Tuesday, July 20, 1999 11:19 PM
Subject: Re: request for review: server/config discussion

> Tom Clarke wrote:
> >
> > How about we get a really good JSP/Servlet engine for V1 and go for a
> > abstracted configuration architecture in V2?
> >
> > What does it really buy us, apart from a really cool design? (Don't get
> > wrong a properly abstracted configuration mechanism would be great - but
> > 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
> > should be a requirement to have multiple engines in a cluster running of
> > same configuration file. Weblogic does this with basic configuration
> > (it has one server which provides config information to the rest I
> >
> > Tom
> >
> agreed. i believe tomcat will be a really good first step for
> a jsp/servlet engine ... although here is and will continue to
> be work in that space pending spec mods, etc.
> with tomcat, we've started to factor out the config stuff and
> i feel the discussion to date excluding my "pieInTheSky" tangent
> is quite viable ... within bounds.
> regarding clusters reading off of the same config file, and i
> intend to flesh this out a bit more in the "config service"
> section of the discussion doc that i've bounced about, i believe
> a "config service" entity (object, service, whatever) can manage
> propogating config data as sourced from a local file or one
> which was sourced via a url. the only real difference, from
> the reading and processing of the data, is the scheme (local
> or remote file) and how best to determine changes (file mod
> data vs ?someDateMimeHeader?). it may not even be necessary for
> the "config service" to manage a singular file but could
> aggregate such data.
> the external config data/objects as provided by the "config
> service" most likely really shouldn't be exposed to the io
> or xml parsing details.
> as i see it anyways.
> <kickInTheButt>
> batting these ideas about here really does help ...
> i/we need to get these thougths captured ... not
> ratified but none the less captured
> </kickInTheButt>
> - james
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message