commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [CONFIGURATION] Which CombinedConfiguration
Date Sat, 24 Oct 2009 17:35:04 GMT

On Oct 24, 2009, at 8:28 AM, Oliver Heger wrote:

> I have now completed a major update of DefaultConfigurationBuilder  
> to use the new combined.CombinedConfiguration class instead of the  
> old one.
> DefaultConfigurationBuilder was the main cause for the existence of  
> duplicated classes because if it switches to the new  
> CombinedConfiguration, all types of sub configurations it supports  
> must be hierarchical. This has been achieved by means of the  
> AbstractFlatConfiguration base class, which simulates a hierarchical  
> configuration on top of a flat one.
> Currently I get 3 test failures. 2 are in  
> TestPreferencesConfiguration and may be unrelated to my changes (a  
> problem with access rights on a windows registry key - I just  
> switched to Windows 7; need to check on a different machine). The  
> other one is in TestMultiFileHierarchicalConfiguration, the test for  
> schema validation. It should not be too difficult to get this test  
> running again, but I am not sure about the desired outcome: The  
> reload causes an exception, which cleared the content of the sub  
> configuration. However, the combined configuration is currently not  
> notified about this change and keeps its (stale) data.

I did not fix reloading in configuration2. Now that you have done the  
major work I should be able to get that done. If I can't get it done  
sooner I definitely plan on doing it during ApacheCon.

> I am not sure whether all changes performed at CombinedConfiguration  
> and DynamicCombinedConfiguration have been applied to the new  
> classes in the combined package. Please have a look. If these  
> classes are merged, we can actually start to remove the old ones.

Thanks. I will do a comparison and make the necessary changes.

> A final remark: I don't know what is required to make the  
> configuration2 branch usable. The approach with  
> AbstractFlatConfiguration is an attempt to make all configuration  
> classes hierarchical. The approach with configuration sources (i.e.  
> the stuff in the base package) has the same purpose, and it seems to  
> be more elegant and powerful. So I would like to follow this path a  
> bit more.

Again, during ApacheCon I hope to spend some time reviewing the  
classes. I would like to end up with HierarchicalConfiguration being  
an interface that is primarily used by applications, especially if the  
configuration is injected by Spring.

Also, I was speaking with a colleague about how multi-valued items are  
supported and he made some suggestions that I am going to look into  
further.  I'll post my thoughts as I really look into that.


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

View raw message