You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Pugh <ep...@upstate.com> on 2004/02/24 14:08:29 UTC
[Configuration] Defaults and CompositeConfiguration Refactoring
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
RE: [Configuration] Defaults and CompositeConfiguration Refactoring
Posted by Eric Pugh <ep...@upstate.com>.
Um.. Yeah.. I guess so.. Although an arguement can be made that most
behaviors can be done as Decorators.. For that matter,
CompositeConfiguration is basicaly just a big fat decorator.
I do think that at somepoint we are going to have many classes in
org.apache.commons.configuration.decorators.. I think decorators will
facilitate things like a reloadable configuration, caching configuration
etc..
If the Defaults way via CompositeConfiguration is confusing, feel free to
submit a DefaultsDecorator...
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:hegero@med.uni-marburg.de]
> Sent: Wednesday, February 25, 2004 8:22 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Configuration] Defaults and CompositeConfiguration
> Refactoring
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Configuration] Defaults and CompositeConfiguration Refactoring
Posted by Oliver Heger <he...@med.uni-marburg.de>.
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
Re: [Configuration] Defaults and CompositeConfiguration Refactoring
Posted by Emmanuel Bourg <eb...@micropole-univers.com>.
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