This is the point of this design:
- enable companies to put the solution they want in place (central, in the
app, environmental, ...)
- enable companies to have a CRUD solution on their official impl (their
central Source) and integrate it smoothly with tamaya for read part
- enable developers to develop without modifying the code (test sources
added in src/test for instance or scope=test) since they use Configuration
without caring where it comes from
- don't provide developers mocked API: read("namespace:*")
I perfectly know it can look limiting and you will think "yes but it is
easy to do X", that's sure but you break at least one of these statements
which makes the solution specific and then a github project is likely
better.
Using these limitations you can already go pretty far and nothing prevents
us to provide things on top of that filling the gaps, will just not be part
of the core API everybody will use and agree on.
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 18:46 GMT+02:00 Werner Keil <[email protected]>:
> 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*
> >
> >
>
