commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [configuration] Configuration 2.0 - Persistence
Date Fri, 12 Jun 2009 22:59:39 GMT
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.


On Jun 12, 2009, at 3:02 PM, Ted Dunning wrote:

> On a related topic, I am interested in building a configuration  
> object that
> pulls configuration from Zookeeper and can optionally persist back  
> to ZK.  A
> key feature would be auto-reload on change combined with a lazily  
> copied
> snapshot so that related properties could be read from a guaranteed  
> stable
> version.  I would also like to support XML and traditional syntaxes  
> and full
> configuration listener capabilities.
> I would prefer not to introduce a Zookeeper dependency into  
> Configuration so
> hacking classes like FileConfiguration seems like a bad idea.   
> Preferably
> there should be some way to do this cleanly that makes use of existing
> configuration code.
> In looking at the API, however, it isn't clear where to go.
> FileConfiguration doesn't seem to be abstract enough and
> AbstractConfiguration seems to have lots of file assumptions built in.
> Likewise, there doesn't seem to be a hookable configuration where I  
> can pass
> in znode contents and use the reload policy framework.
> Where should I start looking?
> On Fri, Jun 12, 2009 at 7:59 AM, Ralph Goers < 
> >wrote:
>> On Jun 12, 2009, at 1:32 AM, Emmanuel Bourg wrote:
>> I may have some time to work on the experimental branch this  
>> summer. There
>>> is a fundamental point I'd like to address, that's the persistence  
>>> of the
>>> configurations.
>>> As described in CONFIGURATION-311 I'd like to add two methods to the
>>> Configuration interface, sync() and flush(), similar to the ones  
>>> in the
>>> java.util.prefs API. I haven't got much feedback on this idea, and  
>>> I'd like
>>> the make sure there is a consensus on this before proceeding.
>>> What do you think?
>>> Here is the part that confuses me. A FileConfiguration would support
>> load() and save() and would have a file name associated with it.  
>> What you
>> are suggesting is that Configuration should have the save() but not  
>> the
>> load()? If so, where would it save to?
>> I see value in having a Configuration where the original data, if  
>> any, is
>> not loaded from a file, but the configuration can be saved to a  
>> file. For
>> example, a CombinedConfiguration is constructed through the merging  
>> of
>> various files but then might be saved as its own configuration.
>> I guess I'd like to understand how you would expect the  
>> configuration to be
>> associated with a file before sync gets called, what happens if it  
>> isn't,
>> etc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message