ConfigFilter does something totally different than ConfigQuery and ConfigOperator. At least as they are implemented today (and this makes sense).
ConfigFilter gets applied after the value is already resolved. It is a filter for the Values. The other two are a lookup mechanism to resolve the targetted key + value. Maybe we should rename ConfigFilter to ValueFilter ? LieGrue, strub > Am 19.07.2016 um 17:59 schrieb Werner Keil <[email protected]>: > > - ConfigFilter > - ConfigQuery > - ConfigOperator > > At most I would see one, but not sure, if it was necessary for an innermost > "core" API > > Either could accomplish what the base element ConfigMergeable does in > Typesafe config. > > From the state and recent contributions I can't say, if now Lightbend still > maintains and cares about this project or completely went to its other > "fancy Cloud" projects like Lagom etc. > > Nevertheless looking at e.g. JCache there are quite a few implementing > projects now, so reaching out to one or another should the time be right > for factoring out the most common denominator is probably a good thing. > > Werner > > > On Tue, Jul 19, 2016 at 5:45 PM, Anatole Tresch <[email protected]> wrote: > >> 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* >>
