That is a very good topic to pick up in fact;-) Mike Keith at a very early stage talked about "CARs" (Configuration Archives)
I know from the current and other large enterprise projects with a more or less "Cloud" and "Microservice" affine approach, that they often use a sophisticated series of JARs. Either via Maven or similar repositories and subsequent naming or through other distribution methods. More and more solutions use either JSON or a JSON-like format or YAML. Others use XML not only on the Spring side. And you'd even find projects where configuration is loaded from some kind of DB. The problem was evident in a similar way when Otavio proposed a "JSR for NoSQL". Given there are so many different types of flavors out there. Hibernate OGM (http://docs.jboss.org/hibernate/ogm/5.0/api/) with significant contributions by Bean Validation Spec Lead Gunnar Morling (according to JavaDoc) managed to get a tiny slim peak to what looks like a giant "iceberg" of API and SPI. Several SPIs, but e.g. DataStoreProvider seems to be used across pretty much every implementation. Hard to say if the same could be done for so many possible ways of retrieving the configuration. DeviceMap only got 3 or 4 variations, but essentially you may have similar options. - Plain File system - Inside an archive - DB - Some sort of service call (URL) e.g. RESTful service Each of those could possibly have variations, Consul, Apache Brooklyn, Salt, Puppet, etc. to plug into. Cheers, Werner On Tue, Jul 19, 2016 at 6:22 PM, Mark Struberg <[email protected]> wrote: > I understand the ratio of not defining the standards for a fixed list of > configuration implementations but I struggle to see how the following 2 > things can be accomplished: > > 1.) How do we define a ’standard configuration’ inside a project, e.g. a > jar? > > 2.) How would you integrate e.g. Consul if there is no SPI to plugin your > integration? It would end up being non-portable across containers, right? > Or did I miss something? > > I need to see an example (sketches) how this would be plugged together > from a user aspect. > > LieGrue, > strub > > > Am 19.07.2016 um 17:45 schrieb Anatole Tresch <[email protected]>: > > > > its me again (inline...) > > > > 2016-07-19 16:34 GMT+02:00 Mark Struberg <[email protected]>: > > > >> I’ll try to explain this once again. Though this has already extensively > >> been covered even in the initial incubator proposal ;) > >> > >> Commons-configuration and DeltaSpike Config / Tamaya do _not_ overlap! > >> > >> * commons-configuration is a collection of tools to read and write > various > >> configuration formats from Java. > >> * Tamaya aggregates a freely extensible list of such configuration > sources > >> in a well specified (ordered) way to a single uniform solution suitable > for > >> consumption by the user. > >> > >> To make it clear: Tamaya is the end-user facing API + the integration > SPI. > >> commons-configuration could be used in custom ConfigSources to leverage > >> various configuration formats. > >> > > > > - > > > that is the reason, why ultimately speaking even the handling of an > > ordered list of property sources is a design decision, which is more than > > questionable if Tamaya's API should already handle it. Providing it such > a > > mechanism as an extension, definitively makes sense, unless we would > > directly reuse DS, which would be possible in such a case ;) > > -> This also allows e.g. in case of unit test mocking/recording/replying > > etc. to configure/use any kind of Configuration (e.g. a thread/test > > isolated JUnit configuration mocker) or simply providing a Java delegate > to > > etcd/consul/zk or whatever system. Not providing any kind of mechanism, > but > > the API also makes us less vunerable to discussions about how > configuration > > should be organized, which ultimately is the main issue, why > standardizing > > it is so difficult. So from a political perspective it may be an > advantage > > NOT to define the mechanisms behind, but only provide the main mechanism > to > > access it, the API. Given use cases such as observing, access control, > > mocking, recording and replying an additional filter/post procerssor > > mechanism could be useful as well: > > > > interface ConfigFilter{ > > Configuration filter(Configuration config); > > } > > > > But that IMO definitivly is it. Given that I think we can easily let the > > configuration implementation details being solved by other frameworks. > E.g. > > DS can easily be used as source, similarly to Spring Configuration, OSGI > > ConfigAdmin etc ;) > > > > Similarly we can also provide such a simple API in multiple languages > such > > as Golang, python, Java and more (as extensions), since it is so > > straightfroward ;) and maybe provide a common REST API on top of it as > > well... Just to give you some ideas beside the Java world ... > > > > > > > > Regarding ‚enhanced Properties‘. That is actually not that far away from > >> what it is! > >> The difference is that a ConfigSource has a name (for > debugging/analysis) > >> and most important: an ordinal number for sorting. > >> And the ‚Configuration‘ interface is basically a way to merge n of those > >> Properties together. > >> > >> Is this part clear now? > >> > >> If so, let’s please come back to Anatoles proposal and my question: > >> If we only have a user facing API but no SPI, how would someone plugin > >> e.g. his default-config into the application? > >> > > > > See above and think on the political aspects ;) I think it would > increase > > the chance for having a JSR quickly. Definitivly we can discuss this kind > > of minimal API at this JavaOne and see how the feedback looks like... > > > > > >> > >> > >> > > > > > > -- > > *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* > >
