tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carreira, Jason" <Jason.Carre...@usa.xerox.com>
Subject RE: request for review: server/config discussion
Date Wed, 21 Jul 1999 15:24:13 GMT
> -----Original Message-----
> From: Greg Wilkins [mailto:gregw@mortbay.com]
> 
> I think the middle ground is to allow detailed notifications, 
> but not to 
> expect modules to be able to handle them.
> 
> Just like a windowing system that might notify that a small 
> region needs
> to be redrawn, but a particular window decides that's all to 
> difficult and
> just redraws the entire window.
> 
> If there is going to be a "something has changed" 
> notification mechanism,
> then it is not too much extra effort to pass a list of 
> names/nodes/whatevers
> that are what have changed.  If the notification observer 
> can't make sense
> of the list, then it can drop it's bundle and restart as 
> nicely as it knows
> how.
> 

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*

Mime
View raw message