You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Anatole Tresch (JIRA)" <ji...@apache.org> on 2017/02/24 10:30:44 UTC
[jira] [Updated] (TAMAYA-145) Adding a complete meta-data schema
usable OOTB
[ https://issues.apache.org/jira/browse/TAMAYA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anatole Tresch updated TAMAYA-145:
----------------------------------
Fix Version/s: (was: 0.3-incubating)
> 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)