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