Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/341
@neykov can you review these additional commits please? Do you agree that
we should merge this, and not @grkvlt 's #279?
When refactoring the tests to remove duplication, I realised that if one
uses:
```
provisioning.properties:
password: $brooklyn:config("password")
```
And then subsequently calls `jcloudsSshMachineLocation.getHostname()`
outside of the context of an entity, then it fails to resolve (because it
doesn't know which entity to look at the config on).
I discussed the short term fix with @neykov, and applied it here: it avoids
propagating the exception if the credentials can't be obtained, and it only
look up the credentials if we really need them (e.g. for hostname on AWS, where
we ask the VM for it).
---
I also discussed the longer term solution with @neykov. Conclusion is that
it's hard. And that we should resolve the DSL config's context at the time the
entity is being instantiated (e.g. storing it as a field on the
`DslConfigSupplier` or whatever). This would mean we'd always use the entity on
which the config was declared, rather than relying on who is looking it up.
However, there is (probably?!) an exception to that rule: if you declare config
with an `@brooklyn:entitySpec`, such as for a `memberSpec`, then you probably
want it to refer to the context of the entity to be created rather than the
entity where you are declaring the entitySpec (and therefore if setting the
entity context on the DSL object, you'd need to ensure it is a different DSL
object instance for each member instantiated using the entitySpec!).
That deserves its own thread on dev@brooklyn.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
