And TomEE has SuperProperties subclass...not sure where you go with it. I suspect you think to the config as Properties which is fine but not what DS* family solves as issue (and also why it exists alongs with [configuration] which is great for your use case and not opposed or a concurrent to DS*).
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 14:44 GMT+02:00 Werner Keil <[email protected]>: > 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* > >> >>> > >> >> > >> > >> > > >
