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 @dslextreme.com 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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
