Re: [configuration] Design discussion
Am 29.01.2013 01:32, schrieb Ralph Goers: 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. I don't have a bright idea how to handle this. I hope, situation gets a bit better when reloading is done differently; then configuration data cannot change completely at any time. It is still on my list for 2.0 to implement a mechanism to make configurations optionally thread-safe. Hopefully, this leads to a solution for CombinedConfiguration, too. 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. Sounds good. Currently I am following a bottom-up approach, i.e. I create the various builders first. It should be possible to implement a 'meta' builder on top later. Oliver 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Design discussion
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
Re: [configuration] Design discussion
(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
Re: [configuration] Design discussion
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
Re: [configuration] Design discussion
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. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
