Am 14.04.2016 um 04:46 schrieb Mansour Al Akeel: > Oliver, > thank you a lot for the detailed response. > What I concluded that I need a wrapper. We need to have a repository > of configurations for a unit testing framework (think JUnit). > We have a setup method, then test cases. So here's what we need: > > 1- A section of the configurations (read-only), holds process wide > configurations, and loaded on start up. > 2- A section for setup (read-only) config, loaded from files > 3- A section for setup method (read/write), that turns becomes > read-only after the setup method exits. For example store a login > token, or similar properties. > 4- A section for data provided by files for each test case. This is > read only. This is erased after each test method. > 5- A section for read-write test data, that gets erased after each test > method. > > Immutable configurations here will complicate things for me. I think > it's better to stay with CombinedConfigurations, and write a > wrapper/proxy that will control access, and manage the repository. Yes, this sounds reasonable. Good luck!
Oliver > > Thank you a lot for your help. > > > On Tue, Apr 12, 2016 at 3:28 PM, Oliver Heger > <oliver.he...@oliver-heger.de> wrote: >> Hi Mansour, >> >> Am 12.04.2016 um 05:39 schrieb Mansour Al Akeel: >>> Hello, >>> >>> I am looking to create a configuration repository, with multiple part, >>> some for read-only, other for read. I found combined configuration >>> suitable for my other requirements, but I was not able to add this mix >>> of read-only and read/write configurations. >> >> I am not sure how exactly your configuration repository looks like and >> which API it provides. >> >> I would recommend the following approach: Use a CombinedConfiguration to >> manage all your configuration settings. This configuration should be >> treated as immutable, e.g. convert it using >> ConfigurationUtils.unmodifiableConfiguration() when exposing it to >> clients. Although CombinedConfiguration has methods for updating >> properties, these capabilities are limited (see [1]). >> >> Your repository component should offer means for querying or updating >> the configurations that can be modified. When adding configurations to >> the combined configuration you can specify names under which these child >> configurations can be accessed; you can use this mechanism to obtain >> references to specific child configurations that can then be updated. >> When a child configuration is manipulated, the combined configuration is >> automatically updated accordingly. >> >> Would this work for you? >> >> Oliver >> >> [1] >> http://commons.apache.org/proper/commons-configuration/userguide/howto_combinedconfiguration.html#Dealing_with_changes >> >>> >>> Any hint ? >>> >>> Thank you. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> For additional commands, e-mail: user-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
