Don't know if somebody else has suggested this before, but wouldn't it
be quite easy to implement this default configuration feature in a
generic way as a decorator?
Oliver
Emmanuel Bourg schrieb:
> Does this change address the complexity of the default configuration use
> case with a composite configuration ?
>
> Emmanuel
>
>
> Eric Pugh wrote:
>
>> Hi all,
>>
>> I wanted to update you on some major surgery I performed on the
>> Configuration package. This amounted to two aspects:
>>
>> 1) Remove "Defaults" from BaseConfiguration and friends.
>>
>> Previously you could declare a PropertiesConfiguration etc and pass in a
>> default configuration value to read from. This was good because you
>> could
>> basically load from two places. However, this wasn't really part of the
>> Configuration interface, so it was only supported by some providers. And
>> this use case is dealt with by the CompositeConfiguration, either
>> alone, or
>> paired with a ConfigurationFactory.
>>
>> This code also caused a lot of bugs, and made testing and understanding
>> things hard, as you always had to go check a Default configuration. By
>> removing this now, versus deprecating it before 1.0, our 1.0 release
>> can be
>> "@deprecated" free!
>>
>> 2) Refactor CompositeConfiguration to extend AbstractConfiguration
>>
>> There were a lot of subtle differences in how things worked between a
>> CompositeConfiguration and any other Configuraiton. For instance, you
>> could
>> do this:
>>
>> myCompositeConfiguration.getString("i.am.an.array.of.values");
>>
>> and get back the first item of the array! But, if you had:
>>
>> myBaseConfiguration.getString("i.am.an.array.of.values");
>>
>> then you would get an exception! There were a host of these. Also, the
>> code was much longer and harder to follow.
>>
>> At this point, all the unit tests now pass. I had to update some of
>> them to
>> deal with the behavior changes in CompositeConfiguration, and I still
>> need
>> to get JNDIConfiguration to extend AbstractConfiguration, but at this
>> point
>> for users of CompositeConfiguration, things should be more deterministic.
>>
>> This change also bumps our code coverage from 85% of lines and 95% of
>> branchs to an astouding 90% of lines and 96% of branches! This I know is
>> some serious surgury, but I think it sets us up for our 1.0 release.
>> Please
>> give it a try, and if there are usecases that are now broken (other
>> then the
>> defaults :-) ) then please let me know, and contribute a test case!
>>
>> I have reformatted the help docs a bit, trying to get them more
>> focused as
>> well.
>>
>> Eric
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Dipl.-Inform. Oliver Heger
Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
Klinikum der Philipps-Universität Marburg
Bunsenstraße 3,
D-35037 Marburg
Tel: +49 6421 28-66592
mailto:oliver.heger@med.uni-marburg.de
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|