[
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 <[email protected]>
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 <[email protected]>
Date: 2016-11-24T16:29:21Z
document better config inheritance semantics
commit 79bb11957be95e525f126d9c7c301635a9fa6404
Author: Alex Heneveld <[email protected]>
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)
