tamaya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anatole Tresch (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAMAYA-145) Adding a complete meta-data schema usable OOTB
Date Tue, 14 May 2019 00:00:48 GMT

    [ https://issues.apache.org/jira/browse/TAMAYA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838960#comment-16838960
] 

Anatole Tresch commented on TAMAYA-145:
---------------------------------------

Upcoming version uses similar format as helidon.io (Hocon). In fact it is format independent,
so metaconfiguration in JSON, HOCON, XML, yaml is supported.

> Adding a complete meta-data schema usable OOTB
> ----------------------------------------------
>
>                 Key: TAMAYA-145
>                 URL: https://issues.apache.org/jira/browse/TAMAYA-145
>             Project: Tamaya
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Anatole Tresch
>            Assignee: Anatole Tresch
>            Priority: Minor
>
> Giving my talks about configuration there was repreatedly questions coming if there is
a way to using Tamaya OOTB, simply taking it ans using it without hacing the need for writing
its property source.
> The ides here is to design and implement an according configuration model, that
> * supports defaults and stages
> * possibly different formats
> * classpath and file system configuration
> * can be setup by a end or system property (stage) and a classpath based config file
(similar to logging.properties)
> Proposal:
> * Use {{tamaya-config.yml}} as global default meta configuration resource for reading
super-configuration entries, multiple files on the same classpath are supported, overrriding
rules as per basic tamaya ordinal functionality.
> * The file allows to define metaconfiguration such as
>   ** the available profiles/stages
>   ** default profiles (active by default)
>   ** the default active profile
>   ** the evaluation rules, how the current active profiles are determined. For the ladder
the resolver module can be leveraged (see example below).
>   ** The suffixes and formats supported can be configured.
>   ** sources expressions can be added that evaluate to a set of PropertySources.
>   ** Hereby "<default>" loads all the PropertySources and PropertySourceproviders
as visible on the classpath.
>   ** It is also possible to select a subset of PropertySources by name
>   ** It is also possible to override (enforce) ordinals to ensure correct ordering as
defined by the DSL.
>   ** additional filters can also be added.
> The final configuration will look similar to the following (most of the part alreadyx
works):
> {noformat}
> TAMAYA:
>   PROFILES-DEF:
>    - selectable:          DEFAULT,DEV,TEST,PTA,PROD
>    - supports-multi:      false
>    - defaults:            DEFAULT
>    - default-active:      DEV
>    - defined-by:          sys-property:ENV, env-property:ENV
>   PROFILES:
>     <COMMON>:
>     - formats:  yaml, properties, xml-properties
>     - suffixes:   yaml, yml, properties, xml
>     - sources:
>       - "named:env-properties"   # provider name, or class name
>       - "named:main-args"
>       - "named:sys-properties"
>       - "resource:classpath:META-INF/config/**/*.SUFFIX"
>     DEFAULT:
>       - prio:       0   # optional
>       - sources:
>         - "resource:classpath:META-INF/defaults/**/*.SUFFIX"
>         - "resource:file:${config.dir}/defaults/**/*.SUFFIX"
>       - filters:
>         - "section:DEFAULTS\.*"
>         - "section:defaults\.*"
>         - "exclude:_\.*"   # removes all meta-entries
>     TEST:
>       - prio:        100   # optional
>       - filters:
>         - "section:TEST\.*"
>         - "section:test\.*"
>     PROD:
>       - prio:        1000   # optional
>       - filters:
>         - "section:PROD\.*"
>         - "section:prod\.*"
> {noformat}
> The meta-configuration hereby is modelled using the Tamaya {{Configuration}} logic using
its {{ConfigurationContextBuilder}}, which proves the flexibility of the current implementation.
The final meta {{configuration}} instance also is programmatically available so other modules
can depend on it for adding their own meta-configuration mechanisms.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message