> Typesafe (I don't suggest you took it from there, just applied similar > code;-)
That ConfigValue<T> is taken from TypedResolver<T> from DeltaSpike. Mostly written by Ron Smeral and Gerhard. > Btw. it's not even remotely Java ME 8 compliant, but let's not > bother discussing it here any more. Target is Java SE and EE, not ME. ME is dead as Elvis, let’s face it ;) LieGrue, strub > Am 19.07.2016 um 16:40 schrieb Werner Keil <[email protected]>: > > 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 >>>>>> >>>>>> >>>>> >>>> >> >>
