Well this is not true since cfg4j contradicts spring on some coercing aspects but main point - cause we speak of all but the thread topic now - is that we need a way to get an aggregated entries accessor, this is Configuration. I think it is what is important for a core. Then other features will likely be built on top of provided by existing frameworks.
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 15:01 GMT+02:00 Werner Keil <[email protected]>: > 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* > > > >> >>> > > > >> >> > > > >> > > > >> > > > > > > > > > >
