Sure - But as I've worked with CombinedConfiguration I became less enthralled with it. The problem I had with the DynamicCombinedConfiguration was that every CombinedConfiguration has to have its own copy of all the configurations. Attempting to share a configuration led to all kinds of corruption when the file was updated and the tree was modified. I really wanted to do the same thing with CompositeConfiguration but since it didn't officially support XML and doesn't have a builder I didn't get around to it.
Ultimately, I would prefer that there only be one ConfigurationBuilder and that its end result be a Configuration, not a CombinedConfiguration. Underneath that there could, of course, be various flavors of builders but ideally the user wouldn't need to be bothered with them. Ralph On Jan 28, 2013, at 1:10 PM, Oliver Heger wrote: > (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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
