(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.
Oliver
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] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
