brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <>
Subject [jira] [Created] (BROOKLYN-267) brooklyn.parameter default value not picked up via inherited config
Date Mon, 16 May 2016 13:57:13 GMT
Aled Sage created BROOKLYN-267:

             Summary: brooklyn.parameter default value not picked up via inherited config
                 Key: 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).

  id: my-example
  version: 1.2.3
    - name: test.myconf
      type:  string
      default: myval
    - type: org.apache.brooklyn.entity.stock.BasicApplication
        myconf2: $brooklyn:config("test.myconf")
        myconf2.from.root: $brooklyn:root().config("test.myconf")
      - type: org.apache.brooklyn.entity.stock.BasicEntity
          myconf3: $brooklyn:config("test.myconf")
          myconf3.from.root: $brooklyn:root().config("test.myconf")

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

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

View raw message