In any case for a minimal footprint and constraints, the entire SPI module and package should probably be separate/optional. With no references from SPI into API (though some JSRs or other libraries tend to do) only the other way round.
E.g. JSR 363 offers the concept of a Unit System (like SI, US, Imperial, etc.) for implementations who like to use it, but the whole SPI is optional, so it's up to users if they retrieve units and quantities via the SPI or just stick them on top of a Java enum (we offer a minimalistic PoC implementation that does just that ;-) Werner On Tue, Jul 19, 2016 at 7:12 PM, Romain Manni-Bucau <[email protected]> wrote: > 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* > > > > > > > > >
