commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [configuration] Configuration 2.0 - Persistence
Date Sat, 13 Jun 2009 05:59:18 GMT
On Fri, Jun 12, 2009 at 5:30 PM, Ralph Goers <ralph.goers@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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message