[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389410#comment-15389410
]
Stefan Seifert commented on SLING-5886:
---------------------------------------
in my prototype i introduced a
[ConfigurationResourceResolver|https://github.com/stefanseifert/sling-config/blob/develop/api/src/main/java/org/apache/sling/config/ConfigurationResourceResolver.java]
which is quite comparable to your ConfigResolver. it may be checked later if
we need really two separate interfaces, but to separate lowlevel from highlevel
features it makes sense i think.
what i've not fully throught through is the nesting support for configurations.
for resources it's easy, they may have children. value maps may support to
access to children as well using "/" in the property name. but this has
limitation when the child is not a singleton but a list of configurations. in
annotations this can be projected to a property referencing another annotation
class, or a list of them
([example|https://github.com/stefanseifert/sling-config/blob/develop/impl/src/test/java/org/apache/sling/config/example/NestedConfig.java]).
> 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)
