[jira] [Commented] (BROOKLYN-267) brooklyn.parameter default value not picked up via inherited config

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BROOKLYN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693808#comment-15693808 ] 

ASF GitHub Bot commented on BROOKLYN-267:
-----------------------------------------

GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/462

    Inherit config default values

    resolve https://issues.apache.org/jira/browse/BROOKLYN-267
    
    also during deserializing migrate to non-deprecated classes

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server inherit-config-default-values

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/462.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #462
    
----
commit 9fb6f35e8b2c694168c06a39b7fcc922b0ece8fc
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2016-11-24T10:56:46Z

    migrate config inheritance to new classes
    
    pioneers use of `readResolve` that actually works brilliantly out of the box due to xstream
    
    also tidying `BasicConfigInheritance` and adding a placeholder (not used yet)
    for resolving ancestor defaults
    
    includes tests for config inheritance serialization

commit 1d5cafca0195275758518e7bba3541ff29298c89
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2016-11-24T16:29:21Z

    document better config inheritance semantics

commit 79bb11957be95e525f126d9c7c301635a9fa6404
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2016-11-17T15:12:09Z

    implement inheritance of config default values
    
    test and code changes to respect the additional inheritance argument added in the previous request:
    resolves https://issues.apache.org/jira/browse/BROOKLYN-267

----


> brooklyn.parameter default value not picked up via inherited config
> -------------------------------------------------------------------
>
>                 Key: BROOKLYN-267
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-267
>             Project: Brooklyn
>          Issue Type: Bug
>    Affects Versions: 0.9.0
>            Reporter: Aled Sage
>            Priority: Minor
>
> When adding the item below to the catalog, I get surprising behaviour when retrieving the "test.myconf" parameter at different levels.
> When inside a child entity, trying to do {{$brooklyn:config("test.myconf")}}, it returns null. But if I do {{$brooklyn:root().config("test.myconf")}} then it works as I'd expect (i.e. I get the default value).
> {noformat}
> brooklyn.catalog:
>   id: my-example
>   version: 1.2.3
>   item:
>     brooklyn.parameters:
>     - name: test.myconf
>       type:  string
>       default: myval
>     services:
>     - type: org.apache.brooklyn.entity.stock.BasicApplication
>       brooklyn.config:
>         myconf2: $brooklyn:config("test.myconf")
>         myconf2.from.root: $brooklyn:root().config("test.myconf")
>       brooklyn.children:
>       - type: org.apache.brooklyn.entity.stock.BasicEntity
>         brooklyn.config:
>           myconf3: $brooklyn:config("test.myconf")
>           myconf3.from.root: $brooklyn:root().config("test.myconf")
> {noformat}
> The reason, I believe, is that {{$brooklyn:config("test.myconf")}} on the child will lookup the child's explicitly defined config keys and not find any. It will therefore create a new {{ConfigKey}} object with no default value. It looks up its own config and then the inherited config, but sees no explicit value set. So it falls back to the configKey.defaultValue. But because we synthesised a new config key object, we don't get the default value that was defined in the {{brooklyn.parameters}} section.
> ---
> Overall, I think it's best if:
> * our exemplar blueprints use things like {{$brooklyn:root().config("test.myconf")}} (because that has a very clear meaning);
> * and we change our config key lookup so that we only synthesis a config key object if none of the current entity or any of its ancestors in the parent hierarchy has a matching config key.
> For point (2), this could lead to surprising behaviour in edge cases where a hierarchy of entities includes something pulled in from another entity type in the catalog, and where that entity type happens to declare a config key by the same name with a default value. At that point, the user looking at their own yaml file might be surprised that it didn't pick up the default value they are looking at in front of them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)