[
https://issues.apache.org/jira/browse/BROOKLYN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aled Sage resolved BROOKLYN-267.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.11.0
> 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
> Fix For: 0.11.0
>
>
> 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.15#6346)
