commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
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.

Ralph

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 <ralph.goers@dslextreme.com 
> >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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message