Yes if you try to "slim the API down to the extreme" then it seems better to either reuse Properties or skip it completely. In DS Configuration is just a tagging interface, but has no method signature. The other types like *Provider or *Source match on a very high level what both Spring Config or Cfg4J do. Spring Config probably works with Spring only but Cfg4J works with Spring, Guice and other DI containers, so it likely has a CDI option, too.
With a skeleton of what more mature and widely used Commons Config provides plus a few aspects from DS Config or Cfg4J, Tamaya is at risk of simply getting lost "in between" those. Werner On Tue, Jul 19, 2016 at 2:46 PM, Romain Manni-Bucau <[email protected]> wrote: > 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* > > >> >>> > > >> >> > > >> > > >> > > > > > >
