[jira] [Commented] (TAMAYA-145) Adding a complete meta-data schema usable OOTB

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on TAMAYA-145:
--------------------------------------------------------

Commit 52c572e8ff428f0fbeda5db0518c5e14e7c0228a in incubator-tamaya-sandbox's branch refs/heads/master from [~anatole]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya-sandbox.git;h=52c572e ]

TAMAYA-145: Removed unused artifacts. Fixed packages.


> 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
>
> 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
(v6.3.15#6346)