Hi Anatole,
so let me explain it in my own words: We will always have an additional
mutable configuration source. It can be changed at runtime. If the
changes will take affect depends on the priority of the mutable property
source. This priority can be also changed at runtime.
If this is correct I would welcome this change.
Bye
Oliver
Am 13.03.16 um 23:00 schrieb Anatole Tresch:
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 ;)
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [email protected]
S oliver.b.fischer
J [email protected]
X http://xing.to/obf
