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*
