tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: request for review: server/config discussion
Date Tue, 20 Jul 1999 21:28:18 GMT
"Craig R. McClanahan" wrote:
> James Todd wrote:
> > "Carreira, Jason" wrote:
> > >
> > > If those values depend on values in the config construct, they should
> > > regsiter themselves as listeners to receive changes from the config object.
> >
> > craig has expressed this request as well and i do like
> > the idea that "a config service listener" can choose to
> > act on config detail changes as deemed appropriate. as i
> > see it, there are two main features (and a couple of sub
> > features):
> >
> >         translate "persistified config data" to the relevant
> >         objects
> >
> >         provide a multi-protocol service to config data
> >         consumers (aka listeners) to:
> >
> >                 read config data (eg server)
> >
> >                 read/write config data (eg tools)
> >
> >                 notify (actively or passively) listner
> >                 that a config change has occurred since
> >                 the last request
> >
> > each of these do need to be stated a bit more explicitly
> > for review but i do believe there is a common goal taking
> > form here.
> >
> There's (at least) one more need to be considered with respect to dynamic
> configurations, and it doesn't fit very neatly into an roles model -- at least
> not in my head.  And that is the idea of asking the currently running server to
> "persistify" (blame James, I am not making this word up :-) the configurations
> data that will reproduce the current environment as faithfully as possible.
> Otherwise, if you make a dynamic change to the running server, but forget to
> make the same change in the config files, you are going to lose that change the
> next time you really do restart the server.

Perhaps I'm weird, but it hadn't occurred to me that this might even be
in the frame. I was assuming that the mechanism was entirely driven by
changing the config files.

I have a horrible feeling someone is going to say "beans" in a moment...

> Doing this would probably be easier if the configurations data was itself an
> object (like a DOM tree or something) that coulld be asked generically to "write
> yourself to this output stream", rather than making every server component for
> reconstructing configurations settings from the currently set properties or
> whatever.





"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

View raw message