tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: request for review: server/config discussion
Date Tue, 20 Jul 1999 20:53:11 GMT
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.

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.

Craig



Mime
View raw message