commons-dev mailing list archives

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


Mime
View raw message