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 Sat, 13 Jun 2009 00:30:28 GMT
Actually, just implementing https://issues.apache.org/jira/browse/ZOOKEEPER-37 
  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.

Ralph

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