Btw, Werner I would prefer if we wouldn't go off-topic in JCP/JSR discussions.
This very thread is about the API design of Tamaya, not about JSRs. Please open a new thread if you like to discuss JCP matters. txs and LieGrue, strub > On Monday, 18 July 2016, 22:08, 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 >>>>> >>>>> >>> >> >> >> >
