Thanks Anatole, It’s a start. But this only covers the consumer part, or did I miss something? What about the SPI part?
Do you think we can live without a way to declare where the configuration comes from? Would this be totally up to the container vendor? How to provide default configuration inside e.g. a jar? @Romain: yes, I also think get(String) is enough, rest is probably sugar. The getProperties() actually makes mostly sense on the ConfigSources (e.g. for an admin/control page) but probably not on the final Configuration instance. txs and LieGrue, strub > Am 19.07.2016 um 13:38 schrieb Romain Manni-Bucau <[email protected]>: > > Ok for ConfigException, ConfigProvider with some rework (see end of the > mail) is ok however I think that: > > - Configuration (as a core API) shouldn't get more than get(String). The > "or default" is sugar we'll add on top of that anyway and getProperties() > implies you can list all entries which can not be possible so I wouldn't do > it in the main core part (DS did it for historical reasons and I think > today it is not the best it could have done) > - I tend to think Filter and Source can be part of the core cause otherwise > you have an entry supplier without any way to provide values. > > > Then about provider: what about just applying bean validation model blindy > first (provider to load a factory to create through a builder API or > through default loading mecanism an instance - of Configuration for us)? I > don't think we can get rid of the provider layer cause it will likely use > ServiceLoader - even in OSGi since it will be part of the impl so fine - > and the provider will then use what is adapted to its env to load other SPI > like sources/filters. > > So it would make a core of (feel free to change name): > > - Configuration { > String get(String); > static Configuration buildDefaultConfiguration() { > byProvider(...loadDefault()...).withSources(...loadDefaults()...).withDeciphers(...loadDefaults()...).build(); > } > static BootConfig byProvider(String); > } > - ConfigurationProvider { > Configuration build(BootConfig) > } > - BootConfig { > withSources(sources...); > withDeciphers(filters...); > Configuration build(); > } > - ConfigurationSource { String get(String); String name(); } // but don't > impl Configuration for future > - ConfigurationDecipher { String decipher(String); String name(); } > > > wdyt? > > > > 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-19 13:18 GMT+02:00 Werner Keil <[email protected]>: > >> Sounds like a plan. >> >> Not sure, if a "general" top level configuration type specialized for >> String allows extending it in another model without some restrictions, but >> if the java.util.Properties like get(String) is of minimalistic use, e.g. >> where it's backed by "good old Properties" anyway why not. Extending it it >> with a flexible type-system would still be possible. >> >> Supplier<String> sounds Java SE 8, so in an API that works both in Java SE >> 6/7 or Java ME 8 that cannot exist. >> >> If a type like ConfigurationProvider is optional, then it would be better >> to put it to another package. Makes building smaller modules easier IMHO, >> otherwise you probably have to use filtering and "Maven magic" to ensure >> only the mandatory or core types are packaged for a "minimal" profile or >> situation while everything is built for a "full" scope. >> >> Werner >> >> >> >> On Tue, Jul 19, 2016 at 12:39 PM, Anatole Tresch <[email protected]> >> wrote: >> >>> For me a point is that I would like to see the API being complete, >> meaning >>> all I need is the API to get a Configuration. Using Java 8 I don't need >> it, >>> so I can provide the ConfigurationProvider for Java 7 only. >> ConfigOperator >>> and -Query are only there for Java 7, they easily vould be removed from >> the >>> API as well. >>> But talking about minimal: a*lso the idea of organizing configuration as >>> property sources is already a design decision the API should not care >> about >>> IMO*. So being really minimal, we need: >>> >>> - Configuration (interface) >>> - ConfigException (exception) >>> - ConfigurationProvider (optional) >>> >>> The key here is Configuration. We agree IMO to provide *single* key >> access >>> for String values. IMO people also expect access to non-String values, >> but >>> this must not be part of the core Configuration interface since it could >>> easily be added as a facade functionality for example, so it can be >>> realized as an extension module! >>> Accessing a Map<String,String> of properties IMO, and also from user >>> feedback, is a wanted functionality. In most cases also the result can be >>> well calculated and further functionality added on top that most people >>> expect from a Configuration solution. This is also what we have done in >> the >>> current source tree (see tamaya-functions module). >>> >>> So my proposal would be: >>> >>> - reduce the API to these 3 artifacts (including ConfigProvider - it >>> doesnt hurt and makes migration from Java 7 to 8 much easier). >>> - Remove type support from Configuration, it can be added in a >> separate >>> module >>> , which is not too much change needed). >>> . >>> - discuss how the ConfigurationProvider loads the Configuration >>> instance to be returned (service loader, OSGI service). >>> - move all the rest of artifacts into separate modules. This also >>> includes the DS inspired parts of PropertySource handling currently in >>> the >>> core module. >>> >>> >>> People already using deltaspike can easily plugin in the DS logic without >>> having to rewrite anything and start using the new API. In CDI >>> Configuration can be determined from using the CDI context (os something >>> else in stages, where CDI is not yet loaded). Same story for Spring and >>> more. >>> >>> This is basically what I proposed in the* tamaya-next branch*: So our >>> complete core API fits into half a page! >>> >>> public interface Configuration { >>> String get(String key); >>> default String getOrDefault(String key, final String defaultValue){...} >>> default String getOrDefault(String key, Supplier<String> >>> defaultValueSupplier){...} >>> Map<String,String> getProperties(); >>> } >>> public final class ConfigurationProvider { >>> [...] >>> Configuration getConfiguration(){ >>> // tbd >>> } >>> } >>> public class ConfigException extends RuntimeException{ >>> private static final long serialVersionUID = -5886094818057522680L; >>> public ConfigException(String message){ >>> super(message); >>> } >>> public ConfigException(String message, Throwable t){ >>> super(message, t); >>> } >>> } >>> >>> J Anatole >>> >>> >>> >>> >>> >>> >>> >>> 2016-07-19 9:08 GMT+02:00 Werner Keil <[email protected]>: >>> >>>> tamaya-api-0.2-incubating.jar is just 30 kb right now. >>>> While the exact set of methods is questionable in the "design study" >>> (just >>>> leave it as that and thanks to EC members like myself or Ben there's no >>>> further damage done by the way it was presented, we're not talking >> about >>>> JCP aspects here now ;-) a minimalistic approach may leave >> Configuration >>>> and ConfigException pretty much the only core elements. Not even sure >>> about >>>> the *Provider. As the name suggests it could be in an SPI, take JCache >>>> (where only its Caching static facade mixes the two and makes clean >>>> separation impossible, CacheProvider is in an SPI package though) >>>> >>>> *Operator and *Query feel a bit redundant and both can be seen as >>> optional. >>>> Especially for implementations based on Java 8 one could probably stick >>> to >>>> Function<Configuration, Configuration> or similar to accomplish that. >> If >>>> Tamaya needs a Java 7 compatibility layer (it'll take years before >>>> especially the Enterprise sector will fully adopt even Java SE and EE >> 7, >>> I >>>> work there all the time and see what's used;-) then it could be in a >>>> different package/jar, but doesn't have to be in a core API. >>>> >>>> Cheers, >>>> Werner >>>> >>>> >>>> On Tue, Jul 19, 2016 at 3:57 AM, Mark Struberg >> <[email protected] >>>> >>>> wrote: >>>> >>>>> Then see it as the smallest possible core. It has only 30 kByte >> (api+RI >>>>> jars). >>>>> It even works on ME or Android. >>>>> >>>>> LieGrue, >>>>> Strub >>>>> >>>>>> Am 19.07.2016 um 01:00 schrieb Werner Keil <[email protected] >>> : >>>>>> >>>>>> We're not talking about the API when it comes to Spring, OSGi or >> even >>>> CDI >>>>>> support. Same for say a YAML module, etc. >>>>>> Those are implementation specific. >>>>>> >>>>>> The more modular and fine-grained the API (of Tamaya) can get, the >>>>> better. >>>>>> >>>>>> CDI has to learn that with V2 only, but for relatively new JSRs or >>>> modern >>>>>> projects it should be considered right from the start. >>>>>> The most basic core API may or may not work even on Java ME >> Embedded. >>>>>> JSR 363, which has a core of only 4 mandatory core types plus 3 >>>>> exceptions. >>>>>> If put in a separate JAR those would only take around 5k. Fits even >>> the >>>>>> smallest Java ME device out there. You may not always be able to >> cut >>>>> things >>>>>> as small in "Server Land" but getting the idea and trying to be >>> modular >>>>>> even before the JDK starts to enforce that with Java 9 is the right >>>>>> approach. >>>>>> >>>>>> >>>>>> On Mon, Jul 18, 2016 at 11:13 PM, Romain Manni-Bucau < >>>>> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Le 18 juil. 2016 23:04, "Werner Keil" <[email protected]> a >>>> écrit : >>>>>>>> >>>>>>>> Tamaya already works with e.g. Spring despite Spring Framework >>>> offering >>>>>>>> Config functionality of its own;-) >>>>>>>> >>>>>>> >>>>>>> Yes but libs cant rely on spring config api without bringing back >>>> spring >>>>>>> core >>>>>>> >>>>>>>> So as there are other config solutions at Apache like Commons >>> Config, >>>>>>>> exclusing CDI because DeltaSpike already uses it sounds odd. >>>>>>>> >>>>>>> >>>>>>> Commons config has no link afaik since it provides nice low level >>> impl >>>>> but >>>>>>> no good end user api/integration. It is also too opiniated to be >>> good >>>>> for a >>>>>>> spec since it has a lot of core methods making it hard to >> integrate >>>> with >>>>>>> all frameworks without limitations. >>>>>>> >>>>>>> That is why tamaya core should be minimal IMO. >>>>>>> >>>>>>>> There are even Apache projects like Tapestry that still offer >> their >>>> own >>>>>>> DI >>>>>>>> mechanism beside a JSR 330/CDI one, so I hope you're not >> suggesting >>>>>>> Tamaya >>>>>>>> should do the same just to "avoid" DeltaSpike?;-O >>>>>>>> >>>>>>> >>>>>>> I'm saying that tamaya core should be light enough to work with >> any >>>>> context >>>>>>> impl and never conflict with them, ie not implementing another >>>> context, >>>>> ie >>>>>>> providing built Config but not store them itself. >>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 18, 2016 at 10:53 PM, Romain Manni-Bucau < >>>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Trying to get back on track... >>>>>>>>> >>>>>>>>> If Tamaya targets CDI it will compete in a useless manner with >> DS >>> or >>>>>>> any >>>>>>>>> specific config API, if it targets contextuality it will with >> any >>>> IoC, >>>>>>> if >>>>>>>>> it targets coercing it will as well with one or both of previous >>>>>>> points. >>>>>>>>> >>>>>>>>> So IMO Tamaya API should be as Mark explained about handling >>> sources >>>>>>> and >>>>>>>>> filters to build on Config which can provide string access - and >>> not >>>>>>>>> properties cause it shouldnt be listable by default IMO. >>>>>>>>> >>>>>>>>> In term of API design I would align it on bval - a factory with >> a >>>>>>> builder >>>>>>>>> or a default loading to get a Config. It is core for me. Mark >>> likes >>>> to >>>>>>>>> count classes: factory + config + provider + source + source >>>> provider >>>>> + >>>>>>>>> filter (we can merge few of them using j8, not sure it is good >> but >>>>>>> would >>>>>>>>> work). >>>>>>>>> >>>>>>>>> Once we agree on that we will have to discuss on top of that: >>>>>>>>> >>>>>>>>> - integrations >>>>>>>>> - injections (injection points vs proxy Bean) >>>>>>>>> - coercion >>>>>>>>> - default impls >>>>>>>>> - .... >>>>>>>>> >>>>>>>>> But making the API small, strong and usable by all is important >>> IMHO >>>>>>>>> >>>>>>>>> Le 18 juil. 2016 22:41, "Werner Keil" <[email protected]> a >>>> écrit >>>>>>> : >>>>>>>>> >>>>>>>>>> Sorry to dissapoint you, but I was involved at least in Tamaya >>>> before >>>>>>>>>> Anatole even proposed it. >>>>>>>>>> I was nearly asked to give the presentation on what later >> became >>>>>>> Tamaya >>>>>>>>> by >>>>>>>>>> Mike Keith when he was stuck in heavy Monsoon rain at GIDS >>> 2011;-) >>>>>>>>>> >>>>>>>>>> I know what Commons Config, Tamaya or DeltaSpike can be used >> for. >>>> And >>>>>>>>>> helped clients who found e.g. DeltaSpike too complex and >>> overloaded >>>>>>> by >>>>>>>>>> contributing to their in-house CDI-based configuration >> framework >>>>>>>>> "inspired" >>>>>>>>>> by it. So Tamaya isn't the only example of API that some find >>> "too >>>>>>>>> much"... >>>>>>>>>> >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jul 18, 2016 at 10:08 PM, Mark Struberg >>>>>>>>> <[email protected] >>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> It seems you do not yet understand the mechanics behind >>> DeltaSpike >>>>>>> and >>>>>>>>>>> Tamaya. Let me elaborate: Properties (and commons-config1&2 as >>>> well >>>>>>> for >>>>>>>>>>> that matter) only handle information from a SINGLE file. >>>>>>>>>>> >>>>>>>>>>> Whereas the ConfigSource approach abstracts that into an >> ordered >>>>>>> stack >>>>>>>>> of >>>>>>>>>>> _multiple_ such 'sources'. And such a >>> ConfigSource/PropertySource >>>>>>> also >>>>>>>>>>> doesn't need to be a single property file. It can be anything >>>> which >>>>>>>>> gives >>>>>>>>>>> access to configuration information. >>>>>>>>>>> >>>>>>>>>>> So yes, it should imo be as easy as property files - even >>> easier. >>>>>>> But >>>>>>>>> it >>>>>>>>>>> is not a _single_ file but many of them. And not only property >>>>>>> files >>>>>>>>> but >>>>>>>>>> a >>>>>>>>>>> freely extensible bunch of different such configuration >> sources! >>>>>>>>>>> >>>>>>>>>>> I hope you _now_ see the huge difference. >>>>>>>>>>> Regarding type-safety: I already wrote that twice: check out >>>>>>>>> ConfigValue. >>>>>>>>>>> (copying the example again): >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>>> This allows for things like >>>>>>>>>>> >>>>>>>>>>>> ConfigValue<Integer> reloadAfterCfg = >>>>>>>>>>>> >> ConfigProvider.getConfig().access("myproject.mydb.reloadAfter") >>>>>>>>>>>> .as(Integer.class) >>>>>>>>>>>> .withDefault(1000) >>>>>>>>>>>> .cacheFor(5, TimeUnit.MINUTES) >>>>>>>>>>>> .evaluateVariables(true) >>>>>>>>>>>> .withLookupPath(config.getValue("myproject.dbvendor"), >>>>>>>>> projectStage); >>>>>>>>>>>> >>>>>>>>>>>> And later use >>>>>>>>>>>> reloadAfterCfg.getValue()--- >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Monday, 18 July 2016, 21:53, Werner Keil < >>>> [email protected] >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> To consider possible simplification and common denominators, >> it >>>>>>> seems >>>>>>>>>>> good to have a look at Tamaya's base interface: >>>>>>>>>>> >>>>>>> >>> http://tamaya.apache.org/apidocs/org/apache/tamaya/Configuration.html >>>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/ImmutableConfiguration.html >>>>>>>>>>>> >>>>>>>>>>>> they have at least some very basic methods in common. Leaving >>> the >>>>>>>>> order >>>>>>>>>>> of key or type aside. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In your proposed Config interface I only saw a >>>>>>>>>>>> String get(String) method, but for that sorry, we could just >>>> stick >>>>>>> to >>>>>>>>>> the >>>>>>>>>>> good old Properties and forget about the whole thing ;-| >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A default or convenience method (what Commons Config 2 calls >>>>>>>>>> getString()) >>>>>>>>>>> why not, but without type-safe yet extensible getters, there >> is >>>>>>> little >>>>>>>>>>> value to create a new API with more or less the same value >>>>>>> (literally) >>>>>>>>>> than >>>>>>>>>>> java.util.Properties. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I know you're on the CDI EG, other than that, not sure, >> which >>>>>>> others >>>>>>>>>>> (according to JCP.org, not mailing lists or other forms of >>>>>>>>> contribution) >>>>>>>>>>>> Being on both sides (EG and EC) in many cases, I am used to >>>>>>> question >>>>>>>>>> JSRs >>>>>>>>>>> and their Spec Leads, so it's not bad if this happens before >> any >>>> of >>>>>>>>> that >>>>>>>>>>> was filed or sonsidered towards a JSR. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Although there had been 2 attempt (one even by Adam Bien at a >>>> very >>>>>>>>> early >>>>>>>>>>> stage of his efforts in the JCP) JSR 377 is an example for a >>>>>>> seemingly >>>>>>>>>>> premature JSR proposal. And unless Andres does some "miracle" >> it >>>>>>> may >>>>>>>>>> likely >>>>>>>>>>> be shut down by the EC with the next Renewal Ballot. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So JCP.next introduced a few measures to avoid "neverending >>> JSRs" >>>>>>> like >>>>>>>>>>> 107 or 310 now, but sometimes it isn't a bad thing to wait or >>> file >>>>>>> it >>>>>>>>>> based >>>>>>>>>>> on experience by one or several Open Source projects. >> Hibernate >>>> was >>>>>>>>> one, >>>>>>>>>>> but considering the JPA RI is based on TopLink (now >> EclipseLink) >>>> it >>>>>>>>>>> certainly isn't the only project behind what became JPA >> either. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Werner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jul 18, 2016 at 9:15 PM, Mark Struberg >>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes Werner, we know. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> But nonetheless Hibernate managed to >>>>>>>>>>>>> >>>>>>>>>>>>> a.) get the spec on the ground pretty efficiently >>>>>>>>>>>>> b.) implemented the JPA specification on top of their own >>> logic >>>>>>> in a >>>>>>>>>>> timely fashion. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As you know I'm contributing to a number of specifications >> as >>> an >>>>>>>>>>> _active_ JCP EG member myself for many years now, so I really >>> know >>>>>>> all >>>>>>>>>> this >>>>>>>>>>> stuff! >>>>>>>>>>>>> >>>>>>>>>>>>> On the original topic: if I say '5 interfaces' than those >>> don't >>>>>>> need >>>>>>>>> to >>>>>>>>>>> be exactly the ones I proposed. I also don't care whether we >>> call >>>>>>> them >>>>>>>>>>> ConfigSource or PropertySource (as example). All I like to do >> is >>>> to >>>>>>>>>> review >>>>>>>>>>> and clean up the API. After all this is a community decision. >>> If a >>>>>>>>>> majority >>>>>>>>>>> of Tamaya committers say I'm nuts and the current API is fine, >>>> then >>>>>>> be >>>>>>>>>> it. >>>>>>>>>>> Otoh if the majority is to do the cleanup then we should do it >>>>>>>>> properly. >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Monday, 18 July 2016, 20:55, Werner Keil < >>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Hibernate vs. JPA is also an interesting read: >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> http://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate >>>>>>>>>>>>>> Like Tamaya, Apache Commons Config or other config >> solutions, >>>>>>>>>>> Hibernate was >>>>>>>>>>>>>> there before JPA. Its creators were involved as well as >> many >>>>>>> others >>>>>>>>>>> (even >>>>>>>>>>>>>> Apache or Novell;-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Werner >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 7:56 PM, Gerhard Petracek < >>>>>>>>>>> [email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> before i vote, i would like to hear if there is a real >>>>>>> blocker >>>>>>>>> for >>>>>>>>>> a >>>>>>>>>>>>>>> simpler api (besides collections). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>> gerhard >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> *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* >>> >>
