I have no problem with using Configuration instead of HierarchicalConfiguration except that it doesn't contain all the necessary methods yet.
I guess from what you are telling me is that the branch is kind of half-way between the 1.x branch and where it is intended to go. That's fine. It just means one more place I can help out :-) Ralph On Thu, Nov 13, 2008 at 1:13 PM, Oliver Heger <[EMAIL PROTECTED]>wrote: > Ralph Goers schrieb: > >> The problem is that in applications using commons config they would like >> to specify an interface in lots of places. HierarchicalConfiguration would >> be perfect for that. It should just extend the Configuration interface. >> > > It was discussed that in configuration2 all configurations are > hierarchical. In this case there would be the single Configuration > interface, but it would offer the enhanced functionality which is now > provided by HierarchicalConfiguration. > > >> I'm also a little confused over CombinedConfiguration and ExpressionEngine >> since two versions of these classes are present. I am assuming that >> combined/CombinedConfiguration and expr/ExpressionEngine are the correct >> classes and the others should be removed? >> > Yes, that's correct. Currently DefaultExpressionBuilder still uses the old > classes because not all Configuration implementations supported by this > class have been converted to the new model. > > Oliver > > > >> Ralph >> >> Oliver Heger wrote: >> >>> Ralph Goers schrieb: >>> >>>> I've noticed that HierarchicalConfiguration isn't part of the >>>> inheritance for the various hierarchical implementations. This seems rather >>>> odd. What base class are applications migrating to configuration2 supposed >>>> to convert all their references to? In fact, I'm wondering if >>>> HierarchicalConfiguration shouldn't just be converted to an interface that >>>> AbstractHierarchicalConfiguration implements. >>>> >>>> Well, first of all, this branch is really experimental and far from >>> being stable. >>> >>> For configuration2 the intension was to make all configurations >>> hierarchical. Because of this there does not seem to be much point in >>> calling a configuration class "HierarchicalConfiguration". >>> >>> The HierarchicalConfiguration class exists there for legacy reasons only >>> because some classes still rely on it. When refactoring is complete it can >>> be removed. With AbstractHierarchicalConfiguration there is a new >>> implementation based on the new NodeHandler approach. (Later this class will >>> probably merge with AbstractConfiguration.) The new counterpart to >>> HierarchicalConfiguration is called InMemoryConfiguration. >>> >>> But, as you certainly see, there is still a lot of work to do, and also >>> some fundamental decisions are pending. For instance, what should be the >>> exact content of the Configuration interface? I am still on the opinion that >>> it would be a good idea to have a low-level ConfigurationSource interface >>> covering only the basics of property access and a high-level Configuration >>> interface providing a rich API with many convenience methods. >>> >>> Oliver >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
