No, that would be premature. As the GitHub repo was. A thread similar to this probably would have been better.
I guess it's best to try breaking the API of Tamaya down and modularize it as good as we can first. It's 0.3 Incubator right now. The project has not even left the incubator. If a configuration JSR was found appropriate, then maybe after JavaOne (when we hear what Oracle really plans for Java EE) it could be worth discussing it further with the EC and possible EG members. Tamaya being approved there should also help. Again that does not mean it was an exact blueprint, but you should see especially from CDI 2 (being in that EG) what effort it is to scale it down from a Full EE standard to be SE or "Micro" compatible. Cheers, Werner On Mon, Jul 18, 2016 at 10:14 PM, Mark Struberg <[email protected]> wrote: > 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 > >>>>> > >>>>> > >>> > >> > >> > >> > > >
