Hi Oliver trying to separate concerns String values are the minimal basics. Conversion could be added in multiple ways. One very powerful concept is using method references, e.g.
T get(String key, Function<String,T> conversion); T getOrDefault(String key, Function<String,T> conversion, T defaultValue); of even using a *Supplier*: T getOrDefault(String key, Function<String,T> conversion, Supplier<T> defaultValueSupplier); String getOrDefault(String key, Supplier<String> defaultValueSupplier); Given that we have a clear separation and conversion logic is completely decoupled, which IMO would be one way to handle that on the low level API level (Configuration). BTW: we had lots of discussions about the Java version to be supported. For a JSR Java 8 must be the base IMO. At least for conversion as above it brings lots of adventages for implementors, see https://github.com/apache/incubator-tamaya/blob/tamaya-next/code/api/src/main/java/org/apache/tamaya/Configuration.java Given that an implementation of Configuration requires only two methods to be implemented ;): String get(String key); Map<String,String> getProperties(); 2016-07-15 16:28 GMT+02:00 Oliver B. Fischer <[email protected]>: > Hi all, > > > Am 15.07.16 um 14:42 schrieb Anatole Tresch: > >> 1) Do we want to support non String values, including type literals? >> > Yes, we need this nowaday. String would work but would never consider a > framework nowadays where I have to do all this by hand. Other frameworks as > Spring supports this out of the box. > >> 2) Do we want to support mutability? OOTB as part of the Configuration >> interface, or indirectly, e.g. by applying some kind of Adapter pattern? >> > I will have to look at the API to answer this. > >> 3) Anything else? >> > Please do not start simply now two overhaul the whole core stuff. I try to > use Tamaya in my projects to get a feeling how it feels to use Tamaya. > Changing the API now would be not helpful for me at least. > > I will have time to help again with the implementation. I think Phil and >> Oliver are also motivated, if we we see a good chance to progress with our >> initiative... ;) So would be great if the other guys could at least join >> discussions here on the list and actively help directing us to do the >> right >> things... >> >> J Anatole >> > > Yes, but we need a better process to define our goals. > > Oliver > > >> >> >> >> 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <[email protected]>: >> >> To be concrete it means: >>> >>> 1. removing auto resolution from tamaya (and provide it through >>> integration >>> modules, cdi/spring/guice/OSGi...) >>> 2. ensure the API is minimal (can be the case, didnt check since few >>> months >>> but last time it got considerations which were not relevant IMO cause of >>> 1 >>> mainly and impl details) >>> >>> I sadly can't help much now but hope to be able to join the effort end of >>> the year (if I don't shout my way, I'll do my best to make it possible >>> ~october) >>> >>> One thing I'd love once the API will be reviewed is to provide a simple >>> tomee-embedded-tamaya-server fatjar providing a REST application and a >>> client "source" to fill the config entries. We would then have a >>> fullstack >>> solution ready to use. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >>> <http://rmannibucau.wordpress.com> | Github < >>> https://github.com/rmannibucau> | >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com> | JavaEE Factory >>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >>> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <[email protected]>: >>> >>> with >>> some >>> whatever >>> a >>> much >>> RI >>> of >>> * >>> >> >> >> > -- > 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 > > -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
