commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [CONFIGURATION] Which CombinedConfiguration
Date Sat, 24 Oct 2009 15:28:07 GMT
Ralph Goers schrieb:
> On Oct 12, 2009, at 12:38 PM, Oliver Heger wrote:
>> Ralph Goers schrieb:
>>> On Oct 10, 2009, at 8:23 AM, Oliver Heger wrote:
>>>> Ralph Goers schrieb:
>>>>> On Oct 7, 2009, at 10:54 PM, Oliver Heger wrote:
>>>>>> ralph.goers schrieb:
>>>>>>> I'm trying to port my changes to fix CONFIGURATION-390 from my

>>>>>>> trunk sandbox
>>>>>>> to configuration2-experimental. But there are two 
>>>>>>> CombinedConfiguration
>>>>>>> classes, one in the main directory and one under combined. Which

>>>>>>> one should
>>>>>>> be removed and which needs the fix?
>>>>>>> Ralph
>>>>>> The one under combined should be the final one. Sorry for the 
>>>>>> confusion.
>>>>> This is a big problem for me. I tried switching 
>>>>> DefaultConfigurationBuilder to the combined/CombinedConfiguration 
>>>>> and got all kinds of errors in TestDefaultConfigurationBuilder 
>>>>> (also switching that to use combined). I've spent days trying to 
>>>>> figure out how to merge the CONFIGURATION-390 changes to the branch 
>>>>> without much luck.
>>>> Obviously the branch is a pretty mess with work started and not 
>>>> finished. I think DefaultConfigurationBuilder still uses the old 
>>>> classes because not all of its dependencies have been ported to use 
>>>> the AbstractHierarchicalConfiguration base class.
>>>> Meanwhile I work on some new ideas in the base package which are yet 
>>>> a different approach.
>>>> No idea how we can clean up things. Maybe I should do my new 
>>>> experiments in a new branch?
>>>> For the reloading problem I wonder whether it makes sense at all to 
>>>> apply these changes to the branch. IMHO we should redesign the 
>>>> reloading operations completely for configuration2.
>>> Rather than making further changes I think it would make sense to 
>>> just get rid of the "old" stuff so that there aren't two 
>>> CombinedConfiguratons, two sets of Combiners and two expression 
>>> engines. Once we are back to just one it should make it easier to 
>>> make changes again.
>> Okay, in the next days I will try how far I get with the reworked 
>> classes, so that we can get rid of the old ones. IIRC I also had some 
>> trouble with DefaultConfigurationBuilder.
>> Did you apply some changes to CombinedConfiguration which are not 
>> ported to combined/CombinedConfiguration?
> Yes. And DynamicCombinedConfiguration as well. But I have a suspicion 
> that other changes weren't applied as well. Hopefully it shouldn't be 
> too hard to do a diff between the two and reconcile the differences.

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

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.


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

View raw message