- ConfigFilter - ConfigQuery - ConfigOperator At most I would see one, but not sure, if it was necessary for an innermost "core" API
Either could accomplish what the base element ConfigMergeable does in Typesafe config. >From the state and recent contributions I can't say, if now Lightbend still maintains and cares about this project or completely went to its other "fancy Cloud" projects like Lagom etc. Nevertheless looking at e.g. JCache there are quite a few implementing projects now, so reaching out to one or another should the time be right for factoring out the most common denominator is probably a good thing. Werner On Tue, Jul 19, 2016 at 5:45 PM, Anatole Tresch <[email protected]> wrote: > 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* >
