brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-267) brooklyn.parameter default value not picked up via inherited config
Date Wed, 18 May 2016 20:44:12 GMT

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

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

Github user aledsage commented on the pull request:

    https://github.com/apache/brooklyn-server/pull/139#issuecomment-220151964
  
    The build error looks unrelated:
    
    ```
    [ERROR] Failed to execute goal on project brooklyn-rest-api: Could not resolve dependencies
for project org.apache.brooklyn:brooklyn-rest-api:jar:0.10.0-SNAPSHOT: Could not find artifact
org.apache.brooklyn:brooklyn-jsgui:jar:tests:0.10.0-SNAPSHOT in Nexus (http://repository.apache.org/snapshots)
-> [Help 1]
    ```
    
    I'm guessing that is down to some strange build environment thing. Maybe something else
was messing with the maven local cache for brooklyn-rest-api while this was being compiled?
Or is our build order and dependencies messed up, with brooklyn-rest-api depending on brooklyn-jsgui
for tests?!
    
    Merging this PR now anyway.


> 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)

Mime
View raw message