You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Werner Keil (JIRA)" <ji...@apache.org> on 2017/02/02 18:51:51 UTC
[jira] [Updated] (TAMAYA-236) Reconsider PropertySource ordering
and getOrdinal()
[ https://issues.apache.org/jira/browse/TAMAYA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Werner Keil updated TAMAYA-236:
-------------------------------
Description:
As marked {TODO rethink whole default PropertySources and ordering} in {PropertySource} we should reconsider the whole {{getOrdinal()}} method.
The Chief Architect of Lightbend (formerly Typesafe), the key contributor to Typesafe Config mentioned in a Microprofile discussion about ordinals, that he's
>unconvinced that the use of ordinals is a preferred solution for the problem >at hand—it just ends up becoming magic numbers which sadly are not >absolutely ordered. It is also extremely finicky since a change in an ordinal >by a third party will lead to surprising effects downstream, most specifically >for config value overloads.
>A deterministic, absolute, order at declaration site means that the >consumer is always in control and order cannot change due to the whims >of third-party libraries.
We may take a look at how e.g. Typesafe Config (and others like Apache Commons Config) handle this, but I am not aware either of them use the concept of an "ordinal" or "order" to solve this problem.
was:
As marked {TODO rethink whole default PropertySources and ordering} in {PropertySource} we should reconsider the whole {getOrdinal()} method.
The Chief Architect of Lightbend (formerly Typesafe), the key contributor to Typesafe Config mentioned in a Microprofile discussion about ordinals, that he's
>unconvinced that the use of ordinals is a preferred solution for the problem >at hand—it just ends up becoming magic numbers which sadly are not >absolutely ordered. It is also extremely finicky since a change in an ordinal >by a third party will lead to surprising effects downstream, most specifically >for config value overloads.
>A deterministic, absolute, order at declaration site means that the >consumer is always in control and order cannot change due to the whims >of third-party libraries.
We may take a look at how e.g. Typesafe Config (and others like Apache Commons Config) handle this, but I am not aware either of them use the concept of an "ordinal" or "order" to solve this problem.
> Reconsider PropertySource ordering and getOrdinal()
> ---------------------------------------------------
>
> Key: TAMAYA-236
> URL: https://issues.apache.org/jira/browse/TAMAYA-236
> Project: Tamaya
> Issue Type: Improvement
> Components: API
> Affects Versions: 0.2-incubating
> Reporter: Werner Keil
> Fix For: 0.3-incubating
>
>
> As marked {TODO rethink whole default PropertySources and ordering} in {PropertySource} we should reconsider the whole {{getOrdinal()}} method.
> The Chief Architect of Lightbend (formerly Typesafe), the key contributor to Typesafe Config mentioned in a Microprofile discussion about ordinals, that he's
> >unconvinced that the use of ordinals is a preferred solution for the problem >at hand—it just ends up becoming magic numbers which sadly are not >absolutely ordered. It is also extremely finicky since a change in an ordinal >by a third party will lead to surprising effects downstream, most specifically >for config value overloads.
> >A deterministic, absolute, order at declaration site means that the >consumer is always in control and order cannot change due to the whims >of third-party libraries.
> We may take a look at how e.g. Typesafe Config (and others like Apache Commons Config) handle this, but I am not aware either of them use the concept of an "ordinal" or "order" to solve this problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)