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 2016/05/05 16:43:12 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:
----------------------------------
Description:
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.
was:
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 the (existing) {{META-INF/javaconfiguration.properties}} as global default configuration resource for reading super-configuration entries:
** {{TAMAYA.stages=a, b, c}} defines the stages available.
** {{TAMAYA.stage.a.priority defines the stages priority
** {{TAMAYA.stage.a.xxxx}} may define other values as needed.
** {{TAMAYA.STAGEDEF.DEFAULTS=a}} denotes stages that are always active.
** {{TAMAYA.STAGEDEF.ACTIVE=b}} denotes the default stage being activ, if none is configured, typically the devloper stage.
** With the env/system property {{tamaya.env}} the current stage environment is set, overriding any configured values.
The final configuration provided hereby will filter the configuration given by the default stages and the active stage. It will use the stage prio as default for the individual property source prios. Similarly for each stage corresponding property sources can be defined with a simple syntax. At the end it should possible to do something like
{noformat}
TAMAYA
STAGEDEF
- stages=DEFAULTS,DEV,TEST,PTA,PROD
- defaults=DEFAULTS
- ACTIVE=DEV
STAGE
DEFAULTS
- prio=0
- source[1]=classpath:META-INF/defaults/**/*.yaml
- source[2]=file:${config.dir}/defaults**/*.yaml
TEST
- prio=100
...
{noformat}
> 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
> Fix For: 0.3-incubating
>
>
> 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.4#6332)