Looking at the many variants and different sources Tamaya already does cover (no DBMSPropertySource yet, but some things could also be left to commercial vendors;-) PropertySource may be a good candidate for a small top level SPI. Whether or not all surrounding objects are absolutely requirement or maybe some could just be replaced by something more simple or general, that's also a good thing to discuss.
The ordinal sounds restrictive, at least the JavaDoc, but it contains a large TODO. If the PropertySourceProvider is also necessary, can't say, but unless that should be totally left to vendors the PropertySource could be a minimal SPI element. Werner On Tue, Jul 19, 2016 at 6:46 PM, Werner Keil <[email protected]> wrote: > 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* >> >> >
