commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Design discussion
Date Mon, 28 Jan 2013 21:10:10 GMT
(From time to time I am going to post an update about the progress I 
have made so that everybody who is interested can comment.)

Just finished reworking MultiFileConfiguration to use the new builder 
approach. There is now a MultiFileConfigurationBuilder class offering 
pretty much the same functionality plus that it can deal with arbitrary 
file-based configurations.

The class now also works well together with CombinedConfigurationBuilder 
in the same way the old integration was with 
DefaultConfigurationBuilder, i.e. a DynamicCombinedConfiguration is used 
to ensure that a new CombinedConfiguration is constructed every time the 
file pattern changes.

@Ralph: Maybe, as the original author, you find the time to have a short 
look to verify that no features were lost?

CombinedConfigurationBuilder should now provide the same functionality 
as DefaultConfigurationBuilder. With slight exceptions it can process 
the same configuration definition files. So I plan to remove 
DefaultConfigurationBuilder shortly.


Am 05.01.2013 16:48, schrieb Oliver Heger:
> Hi Jörg,
> Am 04.01.2013 17:47, schrieb Jörg Schaible:
>> Hi Oliver,
>> Oliver Heger wrote:
>>> Hi,
>>> recently I have worked on code regarding the creation of Configuration
>>> objects and reloading support. I have created two Jira tickets [1, 2]
>>> with a description of the problems I see in the current design.
>>> The code in SVN (mainly in the new builder package) should be sufficient
>>> to get a good impression about the direction I would like to go. It is
>>> far more than a pure proof of concept.
>>> However, following this road means some significant changes in the
>>> design and in the way client code uses our classes. Therefore, I would
>>> really appreciate feedback from other committers also interested in this
>>> component.
>>> My main question is: Can we replace the reloading mechanisms available
>>> in 1.x by an approach based on builders as currently implemented in
>>> trunk (e.g. classes
>>> o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
>>> o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
>>> go forward and significantly simplify most of the file-based
>>> configuration implementations.
>>> Thanks
>>> Oliver
>>> [1]
>>> [2]
>> simply go-on with these changes. IMHO it looks good and since
>> separation of
>> concern leads here to significant code simplification, it's for the
>> best of
>> us devs and also for our users in the long term. Especially since the new
>> approach brings also improved functionality.
> Thanks for your feedback. Will do!
> Oliver
>> Cheers,
>> Jörg
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message