Once again not the issue we try to solve, if you want to use typesafe
config as a reference we want to make the loading strategy able to merge in
a deterministic way the entries of *multiple* sources (see
https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/DefaultConfigLoadingStrategy.java
which doesn't handle it) and let us access through a facade all backing
entries in an already sorted manner.

Then everything on top of that is sugar and specific to each
environment/framework so we'll have to propose something but we need to be
able to load configs before serving it.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-07-19 16:21 GMT+02:00 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
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Reply via email to