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*
