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.go...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
