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, 10 Oct 2009 16:45:21 GMT

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.

The problem with reloading is entirely in how the new tree is  
construcuted. If it is constructed independently and then the root  
node is replaced it is easy to do that atomically. Unfortunately,  
XMLConfiguration has a notion that you can load a configuration and  
then load another one. I ran across the unit test for that in my first  
attempt to fix the problem. The only way to allow that atomically is  
to copy the existing tree, load the new configuration into it and then  
replace the root node. That seems like a lot of work for a feature I'm  
not sure the value of.


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

View raw message