On the top-most API level you'll clearly find some common elements, regardless of each solution's limitations.
NetFlix more or less seems to compensate some when it comes to Commons-configuration. Your "probe" in the impl class showed a few similarities with ConfigImpl by Typesafe (I don't suggest you took it from there, just applied similar code;-) Btw. it's not even remotely Java ME 8 compliant, but let's not bother discussing it here any more. Cheers, Werner On Tue, Jul 19, 2016 at 4:34 PM, Mark Struberg <[email protected]> wrote: > 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. > > 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? > > LieGrue, > strub > > > > Am 19.07.2016 um 15:52 schrieb Werner Keil <[email protected]>: > > > > Unless configuration ends with String jsonBlob = config.get(JSON) or > > xmlBlob = config.get(XML) etc. (could be YAML, too, leaving everything up > > to users of course) the majority of solutions offer a somewhat flexible > > type-system at least within what the JDK has to offer (if nothing else > then > > at least Number and its subtypes) > > > > Even the specialized JCache config subsystem returns more than just > strings > > and I would not say it's a very good example either. > > > > However, if a "tamaya-minimal-api" defined some Configuration type and as > > Anatole also hinted you extend that in a "tamaya-typesafe-api" where a > > TypeSafeConfiguration (names only as examples) offers a more flexible T > > get(String) or similar, nothing is lost. The minimalistic use cases can > use > > the tiny JAR in ME there could be use for that at least and other > > downstream apps and solutions have the choice at which level they use the > > API. > > > > Sounds fine to me. > > > > In any case until Tamaya is used at least by a small fraction of today's > > users of Apache Commons Config (mostly 1, around 4k other apps and > > projects, only 22 so far switched to V2) it's likely too soon to consider > > any standardization based on it. > > > > > > On Tue, Jul 19, 2016 at 3:30 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> 2016-07-19 15:22 GMT+02:00 Werner Keil <[email protected]>: > >> > >>> Well the question is and remains who needs a Properties reboot and how > >> are > >>> applications supposed to use it? > >>> > >>> > >> You don't get our need I think: it is more about the composition than > how > >> it is stored. > >> > >> > >>> Other than commons config or Spring there are no real production usages > >> out > >>> there at the moment. > >>> > >>> > >> Guess the 10* of config solution will thanks you for that. There are a > lot > >> of alternatives and what I'd want we target is the one where the > storage is > >> an implementation detail but enabling the loading of any format. > >> > >> Then I think you focus on how to use it which is not the central point > of > >> the proposal done by DS and CODI. This is often then delegated to the > >> englobing framework and in tamaya it will be in extensions for now > until we > >> got enough adoption to understand what is the righ cursor IMHO. > >> > >> > >>> > >>> > >>> On Tue, Jul 19, 2016 at 3:09 PM, Mark Struberg > <[email protected] > >>> > >>> wrote: > >>> > >>>>> In DS Configuration is just a tagging interface, but has no method > >>>>> signature. > >>>> > >>>> Did you even bother to read the JavaDoc? > >>>> > >>>> > >>> > >> > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/DeltaSpikeConfig.java#L33 > >>>> > >>>> This has absolutely nothing to do with the ConfigResolver + > >> ConfigSource > >>>> approach: > >>>> > >>>> > >>> > >> > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java > >>>> > >>>> > >>> > >> > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java > >>>> > >>>> Would you PLEASE finally stop sidetracking and get back to the > original > >>>> questions? > >>>> > >>>> txs and LieGrue, > >>>> strub > >>>> > >>>> > >>> > >> > >
