Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/155
right, so the use case is one entity wanting to get information from
another. is there no way this can be accommodated using sensors? my
philosophical objection is that we're introducing first-class support for a new
class of dependency injection:
* **0 - simplest - static**: `DEP.x` is set to a constant
* **1 - blocking - sensor**: `DEP.x` can wait if a value isn't ready yet,
ie it is a promise, `$brooklyn:entity(SRC).attributeWhenReady(...)`, which
once resolved is always taken as the value
* **2 - triggering - effector**: every lookup to `DEP.x` invokes a call
somewhere eg `$brooklyn:entity(SRC).effector(...)`
a widespread use of 2 scares me and it's worth avoiding this if at all
possible. it also means lookups aren't idempotent (which is why the
`SideEffecting` marker is introduced here, but it isn't going to work.
could your problem with the CA entity be solved another way, if not with
waiting on a sensor, by the config pointing at the _source entity_ rather than
the key value itself, and whenever it is accessed there is code which invokes
the effector to get the key on that source entity?
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
