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