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. 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
