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
