commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [Configuration] Defaults and CompositeConfiguration Refactoring
Date Wed, 25 Feb 2004 08:38:41 GMT
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


Mime
View raw message