Hi all During development of a MutableConfiguration module I have been seen a new requirement for our API, and I wanted to ask your opinions how we should solve it. First a bit of background:
The mutable module provides an additional singleton, called MutableConfigurationProvider, which allows to access a MutableConfiguration instance. The ladder extends Configuration, but has methods to add/change or remove properties and commit the changes done. I also was playing around separating mutability completely from the existing API, which IMO has the following drawbacks: 1. it creates yet another API. 2. it leads to code redundancies. 3. It leads to additional complexity and the relationship to the existing configuration is also not clear. So I decided to simply extend Configuration and consequently also add a MutablePropertySource, which allows configuration changes being written back. This comes with the following advantages: 1. Registration of mutable property sources is already done by the mechanism in place. 2. Ordering of significance of the instances is also already solved and completely matching with the read mechanism in place. 3. Changes committed may be directly visible, deending on the ordinals/priorities already in place. 4. code, which reads property sources can easily be extended with write capabilities without having to doublicate API or implementation. Overall the ladder mechanism feels now quite good (I ate my own dogfood ;) ). The only thing is that as of now we have: Configuration cfg = ConfigurationProvider.getConfiguration(); // 1 ConfigurationContext ctx = ConfigurationProvider.getConfigurationContext(); // 2 The configuration context is the SPI level of a *Configuration* and therefore strongly coupled with its configuration. To implement the mutable module, the module needs access to a configuration's property sources and therefore to its *ConfigurationContext*. The methods above work fine, but in case I have a Configuration built with a builder or even implemented it otherwise, this design failsm since the provider does not know implementation details on every configuration. *So my proposal is * *1) to add the following method to the Configuration interface, which maps cohesion semnatics better:* * ConfigurationContext getContext();* *2) Deprecate ConfigurationProvider.getConfigurationContext() in favour of the new method.* *3) My behavioural assumptions are the new method must be thread-safe and it never returns null.* WDYT? Cheers, Anatole PS: Given this point is resolved we are ready for release I think ;) -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
