[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389527#comment-15389527
]
Alexander Saar commented on SLING-5886:
---------------------------------------
bq. the primary usecase: you have a complex context-sensitive configuration on
your production systems for a lot of sites/tenants. you want to transfer this
configuration e.g. to testing or staging systems. most parameters still apply,
but some need to be overridden (e.g. site URLs). you do not want to change the
configuration in repository every time, you can just use one of the override
providers (e.g. by command line or a special osgi config) to overwrite e.g. the
site url for certain context paths of for all paths by force.
[[email protected]] I would assume that config typically flows: dev >
int/stage/ua > prod and that ideally you would have those configs somewhere in
a git repo and push it from there. parts of those configs may vary based on the
target system like a service URL. there will also be configs that are managed
by end users in the running system and will not come from git or some other
tool. for those I see that there might be the need to transfer to lower envs
for some testing/verification. but not sure if there are cases where you would
want to overlay those.
not arguing against this. just want to understand the use cases better as I'm
not sure how transparent this behaviour would be in the end
> Sling Configuration - Initial Contribution
> ------------------------------------------
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
>
> as discussed in the mailing list (see [my post from april
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
> i want to contribute the wcm.io Configuration parts that are not
> AEM-specific.
> the current features of wcm.io Configuration are described here:
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means
> configuration that is different for different content paths (e.g. sites,
> tenants).
> during the contribution some changes and refactorings are required/planned,
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and
> support OSGi R6-style annotation classed for typed configuration access
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
