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