[ https://issues.apache.org/jira/browse/TAMAYA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972411#comment-15972411 ]
ASF subversion and git services commented on TAMAYA-145: -------------------------------------------------------- Commit d344e7323db6ec97f3566fd7b893b47093dae771 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=d344e73 ] TAMAYA-145: Added tests, some bugfixes. > 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)