commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ralph.goers @dslextreme.com" <ralph.go...@dslextreme.com>
Subject Re: [Configuration] HierarchicalConfiguration in configuration2
Date Fri, 14 Nov 2008 01:45:48 GMT
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
<oliver.heger@oliver-heger.de>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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message