commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [Configuration] Defaults and CompositeConfiguration Refactoring
Date Wed, 25 Feb 2004 07:22:22 GMT
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


Mime
View raw message