Should be ... left to users, applications or extensions. A Configuration interface with pretty much nothing but get(String) comes back to a slightly "fancier" Properties class but that's about it. There are tons of Properties extensions, e.g. https://docs.jboss.org/jbossas/javadoc/4.0.4/common/org/jboss/util/property/PropertyMap.html has Red Hat EC alternate Scott Stark among its authors;-)
Werner On Tue, Jul 19, 2016 at 2:34 PM, Werner Keil <[email protected]> wrote: > If get(String) only returns a string, how do you imagine it should be used > by real apps. > > Configuration config = ... > String minAsString = config.get("min.value"); > int minValue = Integer.parseInt(minAsString); > String maxAsString = config.get("max.value"); > int maxValue = Integer.parseInt(maxAsString); > ... > > If the rest is "sugar" as you say that boilerplate code is left to > > Archaius, btw. using Apache Commons Config in production already on > https://github.com/Netflix/archaius has the top most feature > > - Dynamic, Typed Properties > > If the configuration was so crippled, then why not just scrap it along the > lines of > > // Change this interface to whatever you want > public interface SampleConfig { > Integer birthYear(); > List<String> friends(); > URL homepage(); > Map<String, Character> grades(); > } > > public static void main(String... args) { > ConfigurationSource source = new GitConfigurationSourceBuilder() > > .withRepositoryURI("https://github.com/cfg4j/cfg4j-git-sample-config.git";) > .build(); > > ConfigurationProvider provider = new ConfigurationProviderBuilder() > .withConfigurationSource(source) > .build(); > > SampleConfig config = configurationProvider.bind("reksio", > SampleConfig.class); > > // Use it! > System.out.println(config.homepage()); > } > > That pretty much goes along the Option Pattern also found in .NET > > https://docs.asp.net/en/latest/fundamentals/configuration.html#options-config-objects > > Btw. believe it or not, a lot of that is also under Apache 2 now coming > from Microsoft;-) > https://github.com/aspnet/Options > > Werner > > > On Tue, Jul 19, 2016 at 1:57 PM, Mark Struberg <[email protected]> > wrote: > >> Thanks Anatole, It’s a start. >> >> But this only covers the consumer part, or did I miss something? >> What about the SPI part? >> >> Do you think we can live without a way to declare where the configuration >> comes from? >> Would this be totally up to the container vendor? >> How to provide default configuration inside e.g. a jar? >> >> @Romain: yes, I also think get(String) is enough, rest is probably sugar. >> The getProperties() actually makes mostly sense on the ConfigSources >> (e.g. for an admin/control page) but probably not on the final >> Configuration instance. >> >> txs and LieGrue, >> strub >> >> >> > Am 19.07.2016 um 13:38 schrieb Romain Manni-Bucau < >> [email protected]>: >> > >> > Ok for ConfigException, ConfigProvider with some rework (see end of the >> > mail) is ok however I think that: >> > >> > - Configuration (as a core API) shouldn't get more than get(String). The >> > "or default" is sugar we'll add on top of that anyway and >> getProperties() >> > implies you can list all entries which can not be possible so I >> wouldn't do >> > it in the main core part (DS did it for historical reasons and I think >> > today it is not the best it could have done) >> > - I tend to think Filter and Source can be part of the core cause >> otherwise >> > you have an entry supplier without any way to provide values. >> > >> > >> > Then about provider: what about just applying bean validation model >> blindy >> > first (provider to load a factory to create through a builder API or >> > through default loading mecanism an instance - of Configuration for >> us)? I >> > don't think we can get rid of the provider layer cause it will likely >> use >> > ServiceLoader - even in OSGi since it will be part of the impl so fine - >> > and the provider will then use what is adapted to its env to load other >> SPI >> > like sources/filters. >> > >> > So it would make a core of (feel free to change name): >> > >> > - Configuration { >> > String get(String); >> > static Configuration buildDefaultConfiguration() { >> > >> byProvider(...loadDefault()...).withSources(...loadDefaults()...).withDeciphers(...loadDefaults()...).build(); >> > } >> > static BootConfig byProvider(String); >> > } >> > - ConfigurationProvider { >> > Configuration build(BootConfig) >> > } >> > - BootConfig { >> > withSources(sources...); >> > withDeciphers(filters...); >> > Configuration build(); >> > } >> > - ConfigurationSource { String get(String); String name(); } // but >> don't >> > impl Configuration for future >> > - ConfigurationDecipher { String decipher(String); String name(); } >> > >> > >> > wdyt? >> > >> > >> > >> > Romain Manni-Bucau >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >> > <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> > <http://www.tomitribe.com> | JavaEE Factory >> > <https://javaeefactory-rmannibucau.rhcloud.com> >> > >> > 2016-07-19 13:18 GMT+02:00 Werner Keil <[email protected]>: >> > >> >> Sounds like a plan. >> >> >> >> Not sure, if a "general" top level configuration type specialized for >> >> String allows extending it in another model without some restrictions, >> but >> >> if the java.util.Properties like get(String) is of minimalistic use, >> e.g. >> >> where it's backed by "good old Properties" anyway why not. Extending >> it it >> >> with a flexible type-system would still be possible. >> >> >> >> Supplier<String> sounds Java SE 8, so in an API that works both in >> Java SE >> >> 6/7 or Java ME 8 that cannot exist. >> >> >> >> If a type like ConfigurationProvider is optional, then it would be >> better >> >> to put it to another package. Makes building smaller modules easier >> IMHO, >> >> otherwise you probably have to use filtering and "Maven magic" to >> ensure >> >> only the mandatory or core types are packaged for a "minimal" profile >> or >> >> situation while everything is built for a "full" scope. >> >> >> >> Werner >> >> >> >> >> >> >> >> On Tue, Jul 19, 2016 at 12:39 PM, Anatole Tresch <[email protected]> >> >> wrote: >> >> >> >>> For me a point is that I would like to see the API being complete, >> >> meaning >> >>> all I need is the API to get a Configuration. Using Java 8 I don't >> need >> >> it, >> >>> so I can provide the ConfigurationProvider for Java 7 only. >> >> ConfigOperator >> >>> and -Query are only there for Java 7, they easily vould be removed >> from >> >> the >> >>> API as well. >> >>> But talking about minimal: a*lso the idea of organizing configuration >> as >> >>> property sources is already a design decision the API should not care >> >> about >> >>> IMO*. So being really minimal, we need: >> >>> >> >>> - Configuration (interface) >> >>> - ConfigException (exception) >> >>> - ConfigurationProvider (optional) >> >>> >> >>> The key here is Configuration. We agree IMO to provide *single* key >> >> access >> >>> for String values. IMO people also expect access to non-String values, >> >> but >> >>> this must not be part of the core Configuration interface since it >> could >> >>> easily be added as a facade functionality for example, so it can be >> >>> realized as an extension module! >> >>> Accessing a Map<String,String> of properties IMO, and also from user >> >>> feedback, is a wanted functionality. In most cases also the result >> can be >> >>> well calculated and further functionality added on top that most >> people >> >>> expect from a Configuration solution. This is also what we have done >> in >> >> the >> >>> current source tree (see tamaya-functions module). >> >>> >> >>> So my proposal would be: >> >>> >> >>> - reduce the API to these 3 artifacts (including ConfigProvider - it >> >>> doesnt hurt and makes migration from Java 7 to 8 much easier). >> >>> - Remove type support from Configuration, it can be added in a >> >> separate >> >>> module >> >>> , which is not too much change needed). >> >>> . >> >>> - discuss how the ConfigurationProvider loads the Configuration >> >>> instance to be returned (service loader, OSGI service). >> >>> - move all the rest of artifacts into separate modules. This also >> >>> includes the DS inspired parts of PropertySource handling currently >> in >> >>> the >> >>> core module. >> >>> >> >>> >> >>> People already using deltaspike can easily plugin in the DS logic >> without >> >>> having to rewrite anything and start using the new API. In CDI >> >>> Configuration can be determined from using the CDI context (os >> something >> >>> else in stages, where CDI is not yet loaded). Same story for Spring >> and >> >>> more. >> >>> >> >>> This is basically what I proposed in the* tamaya-next branch*: So our >> >>> complete core API fits into half a page! >> >>> >> >>> public interface Configuration { >> >>> String get(String key); >> >>> default String getOrDefault(String key, final String >> defaultValue){...} >> >>> default String getOrDefault(String key, Supplier<String> >> >>> defaultValueSupplier){...} >> >>> Map<String,String> getProperties(); >> >>> } >> >>> public final class ConfigurationProvider { >> >>> [...] >> >>> Configuration getConfiguration(){ >> >>> // tbd >> >>> } >> >>> } >> >>> public class ConfigException extends RuntimeException{ >> >>> private static final long serialVersionUID = -5886094818057522680L; >> >>> public ConfigException(String message){ >> >>> super(message); >> >>> } >> >>> public ConfigException(String message, Throwable t){ >> >>> super(message, t); >> >>> } >> >>> } >> >>> >> >>> J Anatole >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> 2016-07-19 9:08 GMT+02:00 Werner Keil <[email protected]>: >> >>> >> >>>> tamaya-api-0.2-incubating.jar is just 30 kb right now. >> >>>> While the exact set of methods is questionable in the "design study" >> >>> (just >> >>>> leave it as that and thanks to EC members like myself or Ben there's >> no >> >>>> further damage done by the way it was presented, we're not talking >> >> about >> >>>> JCP aspects here now ;-) a minimalistic approach may leave >> >> Configuration >> >>>> and ConfigException pretty much the only core elements. Not even sure >> >>> about >> >>>> the *Provider. As the name suggests it could be in an SPI, take >> JCache >> >>>> (where only its Caching static facade mixes the two and makes clean >> >>>> separation impossible, CacheProvider is in an SPI package though) >> >>>> >> >>>> *Operator and *Query feel a bit redundant and both can be seen as >> >>> optional. >> >>>> Especially for implementations based on Java 8 one could probably >> stick >> >>> to >> >>>> Function<Configuration, Configuration> or similar to accomplish that. >> >> If >> >>>> Tamaya needs a Java 7 compatibility layer (it'll take years before >> >>>> especially the Enterprise sector will fully adopt even Java SE and EE >> >> 7, >> >>> I >> >>>> work there all the time and see what's used;-) then it could be in a >> >>>> different package/jar, but doesn't have to be in a core API. >> >>>> >> >>>> Cheers, >> >>>> Werner >> >>>> >> >>>> >> >>>> On Tue, Jul 19, 2016 at 3:57 AM, Mark Struberg >> >> <[email protected] >> >>>> >> >>>> wrote: >> >>>> >> >>>>> Then see it as the smallest possible core. It has only 30 kByte >> >> (api+RI >> >>>>> jars). >> >>>>> It even works on ME or Android. >> >>>>> >> >>>>> LieGrue, >> >>>>> Strub >> >>>>> >> >>>>>> Am 19.07.2016 um 01:00 schrieb Werner Keil <[email protected] >> >>> : >> >>>>>> >> >>>>>> 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 >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> *Anatole Tresch* >> >>> PPMC Member Apache Tamaya >> >>> JCP Star Spec Lead >> >>> *Switzerland, Europe Zurich, GMT+1* >> >>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> >> * >> >>> *Twitter: @atsticks, @tamayaconf* >> >>> >> >> >> >> >
