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.
That is an interesting option if there is some way for a provider to
signal
changes. Presumably from your language, it sounds like it would be
possible
to build a ZK vfs provider without introducing a ZK dependency in
vfs. Is
that correct?
Building a new provider is relatively easy once you come up to speed
on AbstractFileObject, AbstractFileProvider and AbstractFileSystem,
all of which you will probably want to extend. I looked at the HTTP
provider and the old webdav provider when I reimplemented the webdav
provider.
VFS supports events for a file change, creation or deletion.
Applications can register listeners for these events with the
FileSystem. If you look at the latest version of
VFSFileMonitorReloadingStrategy you will see how these events can be
used to cause file reloading to occur in Commons Configuration. You
would also want to extend DefaultFileMonitor to accept the automatic
notifications since it wouldn't need to poll for changes.
VFSFileMonitorReloadingStrategy would then need to be modified to be
able to be configured with that class.
If you wanted to create the provider in some other project that would
be fine and VFS can detect it and add it or it can be added to VFS,
whichever makes more sense. VFS is constructed to handle new providers
nicely. The configuration file that describes the providers allows you
to specify required classes. So you can specify a ZK dependency that
must be present. If it isn't than the ZK provider just won't be made
available.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
