On Fri, Jun 12, 2009 at 5:30 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
> Actually, just implementing > https://issues.apache.org/jira/browse/ZOOKEEPER-37 would be even easier. It would be easier, but it would lose the notifications. > But from what I am guessing you want to have Zookeeper itself be treated as > a single Configuration. To do that you would probably need to extend > HierarchicalConfiguration. You can't really extend any of the > FileConfigurations because they want to load the entire configuration where > I would imagine you would only want to load the parts of the tree that get > accessed. No. I just wanted a surrogate for file storage. I definitely would not want to load a recursive tree. The point is central storage of a configuration file with magic updates whenever it changes and without polling for changes. > On Jun 12, 2009, at 3:59 PM, Ralph Goers wrote: > > Pardon my ignorance, but I know nothing about Zookeeper. I gave the >> documentation a cursory glance but I didn't see anything that looked like >> configuration manipulation. But if a znode is similar to a file or folder >> than it would seem that if it can be implemented as a provider in Commons >> VFS then Commons Configuration can use it as the persistence store. > > That is an interesting option if there is some way for a provider to signal changes. Presumably from your language, it sounds like it would be possible to build a ZK vfs provider without introducing a ZK dependency in vfs. Is that correct?
