I’ll post it again (4th time now) despite you will most probably not read it again:
Integer myInt = ConfigProvider.access(„my.config.key“).as(Integer.class).getValue(). What part isn’t type-safe with this code? Can you explain it, pretty please? LieGrue, strub > Am 19.07.2016 um 16:21 schrieb Werner Keil <[email protected]>: > > The other most widely used framework, Typesafe config itself looks like a > compromise, but roughly 1.5k downstream usages mean, it's also one people > can live with. > > It has no extensible type system but exposes all sorts of standard JDK > types from String to Number (and all primitive numbers), Enum as well as a > few of the new Java 8 elements like Duration. Plus a JSON dialect called > HOCON (https://github.com/typesafehub/config/blob/master/HOCON.md) which > even recognizes "kilobyte" but that's about it. For times it sticks to Java > 8 Date/Time parsing, otherwise there are numeric or string values. > > Werner > > > On Tue, Jul 19, 2016 at 3:52 PM, Werner Keil <[email protected]> wrote: > >> 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 >>>>> >>>>> >>>> >>> >> >>
