commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Configuration 2.0 - Persistence
Date Sat, 13 Jun 2009 15:03:08 GMT
Ralph Goers schrieb:
> 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.
> Ralph
There are certainly some use cases that would benefit from a generic 
flush() method, e.g. just tell a composite configuration to save its 
changes, and it iterates over its children and flushes them.

However, there are lots of details that have to be cleared, for instance:
- How are configurations treated that are not really "compatible" with a 
manual save operations, e.g. JNDIConfiguration or DatabaseConfiguration?
- What about pure in-memory configurations?
- Or URL-based configurations without a valid URL?

Not sure how a sync() operation would fit into the concept of the 
library. I assume it is like a manual reload, but (in addition to the 
questions above):
- What happens to changes performed on the configuration objects? Are 
they overridden? Is a merge tried?
- When in the life-cycle of a typical application should the sync() 
method be called?

Solutions to these questions are not easy and may sometimes be non 
intuitive. So I worry this might be confusing for users and generate 
some Jira tickets.

In summary: I see some use cases for this feature, but I wonder whether 
it is worth the effort.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message