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 > > >>>> > > >>>> > > >> > > > > > > > > > > > >
