There is no ConfigProvider in Tamaya ;-) If the one you sketched out has relevance to the ConfigurationProvider in Tamay, then sure, that's another thing to discuss. If you stick to string based getters and setters and offer some extension (ConfigurationProvider.access(„my.config.key“).as(Integer.class).getValue() or any other names sound very bulky and error-prone unless you back it with say JDK 8 Optional but as SPI there would always be an alternative to wrap something else around it to make it prettier)
With or without such functionality and methods I feel *Provider was a case for an SPI, other thoughts? Werner On Tue, Jul 19, 2016 at 4:37 PM, Mark Struberg <[email protected]> wrote: > 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 > >>>>> > >>>>> > >>>> > >>> > >> > >> > >
