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