Do you suggest to use Bean Validation for Tamaya? Werner
On Tue, Jul 19, 2016 at 5:04 PM, Romain Manni-Bucau <[email protected]> wrote: > Guys, > > Can we stop there and can you review the proposal based on bval? > > Negative answers should say why and propose an alternative. > > This thread starts to be long and not sure we ll see the end if we dont > focus on small steps. > > Thanks > > Le 19 juil. 2016 16:58, "Mark Struberg" <[email protected]> a > écrit : > > > > 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 > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > > > >
