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