Well the TypeLiteral in Tamaya was also at least very much inspired by CDI. Unlike an IoT JSR like 363 where being as small as possible (so everything above JavaCard can run it) this type of standard can probably afford to start at SE.
Werner On Tue, Jul 19, 2016 at 4:58 PM, Mark Struberg <[email protected]> wrote: > > 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 > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
