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 Sat, 13 Jun 2009 00:30:28 GMT
Actually, just implementing 
  would be even easier.

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.


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.
> 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 < 
>> >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