tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Clarke" <tcla...@agency.com>
Subject Re: request for review: server/config discussion
Date Wed, 21 Jul 1999 04:02:03 GMT
I meant to say 'multiple configuration mechanisms' - if that makes any
difference to your answer - are you really using say LDAP and a
configuration file mechanism?

I think seperating configuration info to the Web application context is a
_very_ good idea.

One of the issues I am having to deal with at the moment is a Weblogic
server that is shared between multiple parts of a Website - only one of
which I'm responsible for developing. It would be massively more convenient
if the configuration specific to my application was seperated out.

I think one of the additional issues we are attempting to deal with here
though is allowing application configurability through the webserver
configuration mechanism. This could well be very useful.

However, I tend to work in a three-server environment
(dev->stage->production) and one of the things you notice with configuration
is that:
    a) There is some stuff which is specific to each server (its name, which
database is being accessed, what the email address of the admin)
    b) There is some stuff which you want to be included when you run the
roll scripts.

We've dealt with this up to now by having one configuration file that sits
just about the webserver root and one that sits just below.


Tom



Tom Clarke
Senior Software Engineer
AGENCY.COM
v 212.358.2798
----- Original Message -----
From: James Todd <james.todd@eng.sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, July 20, 1999 11:51 PM
Subject: Re: request for review: server/config discussion


> Tom Clarke wrote:
> >
> > 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?
>
> the app running behind javashop.sun.com
> (JWS 1.1.3/jhtml/jdbc/javaMail,etc) uses such a beast to manage
> lots of, al be it application scoped, very configurable fields
> (hence my belief that name/value will only get one so far).
> this system is 2.5 years old and based on a previous 2+ years work
> based on apache/tcl. it is "yetAnotherEComApplication" yes but
> it is one that, collectively, is 4+ years old ... before the
> eThis and eThat craze that is all the buzz these days ... back to
> the topic at hand ... to require a system restart for this system
> for many of the changes required by an extraNet aware web application
> would've simply killed us. i won't get into the config data details
> unless that'd help you here but i will add that i feel a certain
> amount of a web server should allow for more flexibility with regards
> to eased system constraints pertaining to configurabilty, namely
> web application context (a servlet 2.2 entity) then what we just
> live with today. if this is solved in a nice manner then at least
> we have options for those who feel this is an important feature.
>
> softned config management will help for production systems i believe
> and is a sure help for developers of said systems or server/servlet
> engines ... such as tomcat. tomcat is primed for taking advantage of
> this sort of config service without polluting it's core servlet,
> jsp and http implementations what so ever.
>
>
> > One of the things that Weblogic allows you to do, is have configuration
> > specific to an individual server that overrides the global
configuration.
> >
>
> ahhh ... yep, i believe this will be a ?name? space management
> item the proposed "config service" will have to sort out ... in
> communicating with config consumers (eg server). in the early
> days i believe we can make some assumptions during the proto-cycle
> yet keeping an eye on the bigger picture all the while.
>
> - james
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


Mime
View raw message