Sometimes it is hard to follow your dicussions if you are not online the
whole day... ;-)
Am 22.01.15 um 19:59 schrieb Romain Manni-Bucau:
1) ok
2) we spoke about it earlier but I think here a builder would be the
easiest and cleaner solution. Extensions can work on the builder IMO
but shouldn't be able to modify at runtime the configuration itself.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-22 19:44 GMT+01:00 Anatole Tresch <[email protected]>:
Hi Romain¨
so lets focus on the first aspect:
1) I would agree to provide ConfigurationProvider as an accessor singleton
class in Java 7 and 8 similarly. As a consequence I would agree to
remove Configuration.current()
in Java 8 and use ConfigurationProvider as the entry point into Tamaya
config.
2) I would then define a ConfigurationProviderSpi, which implements exactly
how Configuration instances are managed, depending on the context or
whatever is appropriate. This class is loaded from the ServiceContext once
and then hold as a static variable within ConfigurationProvider. What is
happening inside ConfigurationProvider/ConfigurationProviderSpi is
basically completely transparent. In SE it will be true singleton, in
EE/OSGI environments something different perhaps.
-> This should give you a direct OOTB API to decide how Configuration
instances are managed.
2a) If we would remove ConfigurationContext, we might add the method
/**
* This method can be used for programmatically adding {@link
PropertySource}s.
* It is not needed for normal 'usage' by end users, but only for
Extension Developers!
*
* @param propertySourcesToAdd the PropertySources to add
*/
void addPropertySources(PropertySource... propertySourcesToAdd);
to the Configuration interface.
2b) The other methods look nevertheless somehow detailed, and when writing
extensions they may be still very helpful. So basically if we want to
remove ConfigurationContext completely some of them would end up on
Configuration.
Best we can do is probably to add a method ConfigurationContext
getContext() on Configuration, or on ConfigurationProvider. Disadvantage is
that PropertyFilter and PropertySource also get API artefacts (basically
PropertyConverter already is one, since it can be passed as parameter for
adhoc conversion), so let's see what Mark thinks on that...
WDYT? Would that match at least first couple of aspects you mentioned?
-Anatole
2015-01-22 17:47 GMT+01:00 Romain Manni-Bucau <[email protected]>:
--
*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*
--
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
