Aled Sage created BROOKLYN-267:
----------------------------------
Summary: 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)
