[
https://issues.apache.org/jira/browse/BROOKLYN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15714672#comment-15714672
]
Alex Heneveld commented on BROOKLYN-329:
----------------------------------------
The test above seems to hang and that makes sense. We say
brooklyn.config: { my.param.key:
$brooklyn:scopeRoot().config(\"my.param.key\") }
The `scopeRoot` does nothing, correctly as I understand it: the parent, ie the
Application, does not have the same catalog item ID, so it returns the child
entity. (It only make sense to see runtime instances; I think the bug report's
claim it returns `entity-with-tests` (meaning `entity-with-keys` ?) is
mistaken.)
Essentially we are saying that . `my.param.key` should be resolved to the value
of `my.param.key`, ie setting up an infinite loop of tasks and making the
system crap out.
So concretely:
1) clarify what the test is meant to do; I think it wants to remove the
brooklyn.config from wrapper-entity ? such a test passes for me (with the
changes in #440 and #462, probably the former) and suggests the original bug
reported here is fixed ?
2) test for recursive references in config evaluation and throw an exception
(add task tags? traverse parent tasks?) -- it's a nasty issue to debug otherwise
[~aled.sage] does that sound right?
> $brooklyn:config hangs, rather than getting default brooklyn.parameter value
> ----------------------------------------------------------------------------
>
> Key: BROOKLYN-329
> URL: https://issues.apache.org/jira/browse/BROOKLYN-329
> Project: Brooklyn
> Issue Type: Bug
> Reporter: Aled Sage
> Priority: Minor
>
> Using 0.10.0-SNAPSHOT...
> I wrote a YAML entity where CouchDB was configured with an initial
> username/password, and another app that included CouchDB would inject it.
> In each blueprint, I defined a brooklyn.parameter with a default value for
> the username/password. I used the same config key name in each.
> However, when I ran my blueprint it hung. The CouchDB was waiting forever for
> the username/password config value.
> I recreated this behaviour in the simpler test case below (which I'll add to
> {{ConfigParametersYamlTest}}).
> The workaround is to use a different name for the config key in each
> blueprint. For example, in the outer blueprint above if youchange the name to
> {{my.param.key2}} then the test passes.
> Debugging it, one surprising thing I noticed is that {{scopeRoot()}}
> evaluates to be "entity-with-tests" rather than {{wrapper-entity}}.
> {noformat}
> public void testConfigParameterPassedFromOuterConfigParameter() throws
> Exception {
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: entity-with-keys",
> " item:",
> " type: "+TestEntity.class.getName(),
> " brooklyn.parameters:",
> " - name: my.param.key",
> " type: string",
> " default: myDefaultVal",
> " brooklyn.config:",
> " my.other.key: $brooklyn:config(\"my.param.key\")");
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: wrapper-entity",
> " item:",
> " brooklyn.parameters:",
> " - name: my.param.key",
> " type: string",
> " default: myDefaultValInOuter",
> " type: entity-with-keys",
> " brooklyn.config:",
> " my.param.key:
> $brooklyn:scopeRoot().config(\"my.param.key\")");
>
> String yaml = Joiner.on("\n").join(
> "services:",
> "- type: wrapper-entity");
>
> Entity app = createStartWaitAndLogApplication(yaml);
> final TestEntity entity = (TestEntity)
> Iterables.getOnlyElement(app.getChildren());
> Asserts.assertReturnsEventually(new Runnable() {
> public void run() {
>
> assertEquals(entity.config().get(ConfigKeys.newStringConfigKey("my.other.key")),
> "myDefaultValInOuter");
> }},
> Asserts.DEFAULT_LONG_TIMEOUT);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
