[
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)
