@Werner: let's agree on API/SPI then see if we spli it or not. That said if you look to the proposed design splitting it doesn't make much sense.
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 19:21 GMT+02:00 Werner Keil <[email protected]>: > 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* > > > > > > > > > > > > > >
