tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: request for review: server/config discussion
Date Wed, 21 Jul 1999 17:23:15 GMT
"Carreira, Jason" wrote:

> Hmm... I would think it would be better to build the config object as nested
> containers, where each container can hold config properties and other
> containers. Then, a listener can register itself at whatever granularity it
> needs to get the config info specific to it. ie. a specific web app only
> needs to listen for changes to it's config and configs of sub-components.
> Then, when there's a change to a config container, it notifies it's
> listeners, and passes the message up to its parent, for it to notify its
> listeners, and so on...
> I also think we should stop worrying about how this will be implemented in
> XML and think instead about the API and config server, especially about
> persisting the config object tree. Perhaps each config container can be
> responsible for persisting itself.
> After reading a bit about Eneterprise Javabeans, I really think there's a
> lot to be learned there for this project, especially wrt persistence and
> transactional content. I think the config object should probably proivide a
> transactional context, so batch updates can succeed or fail atomically, and
> then immediately persist itself to one-or-more of the storage mechanisms
> discussed here (XML, JNDI-LDAP, etc.) which should be implemented as plugins
> with a common interface.
> But maybe I'm getting pie-in-the-sky too.... *grin*

i think you've recapped the "state of the world" with regards
to this discussion nicely. i concur completely.

i believe i'll get another cut of the discussion draft out
today which should help us to come up with some consistent
terminology and get to the next level of discussion.

- james

View raw message