You could add an isSet enricher then wait on it. I prefer customisation in enrichers rather than extending the dsl.
What is the use case? Everywhere I've seen whenReady is the most natural. Best Alex On 5 Aug 2016 17:07, "Aled Sage" <[email protected]> wrote: > Hi all, > > Motivated by Andrew's recent PR [1] and Svet's suggestion, I'd like to > propose a change to the semantics/arguments to > $brooklyn:attributeWhenReady(). > > _*Current Behaviour*_ > > _Simple example_ > If you write in a YAML blueprint something like: > > brooklyn.config: > myurl: $brooklyn:component("db").attributeWhenReady("datastore.url") > > then when you attempt to get the config value for "myurl" it will block > until the "datastore.url" sensor value is available on the entity with id > "db". > > _"Groovy truth" example_ > The attributeWhenReady actually blocks until groovy truth is satisfied > (boolean is true, collection is non-empty, string is non-empty, etc). > > You can therefore write: > > brooklyn.config: > launch.latch: > $brooklyn:component("db").attributeWhenReady("service.isUp") > > and it will block until the db entity's service.isUp sensor is true. > > Unfortunately this means it's impossible to wait for a boolean attribute > to be non-null (i.e. stop waiting when false or true). > > _Java API Functionality_ > Comparing the yaml DSL with what can be done in DependentConfiguration > [2], there is a lot we can't do: > > * customize the "readiness" function (i.e. what sensor values mean > "ready") > * define "abort conditions" (e.g. stop waiting if the entity > transitions to some other state) > * specify a timeout > * give a default value for if there is a timeout, or if the entity is > removed while we're waiting. > > > _*Proposal: option 1*_ > > My favoured option is to make attributeWhenReady more configurable. > > For example, we could support: > > brooklyn.config: > launch.latch: $brooklyn:component("db").attributeWhenReady: > sensor: "service.isUp" > readiness: $brooklyn:predicates.equalTo("true") > timeout: 10m > > Maybe we'd support overloading of in-lining the args (relying on parameter > order of [sensor, readiness, timeout]), such as: > > brooklyn.config: > launch.latch: > $brooklyn:component("db").attributeWhenReady("service.isUp", > $brooklyn:predicates.equalTo("true"), 10m) > > I think I'm ok with leaving the default as groovy-truth semantics, as long > as we make the documentation clearer for that. > > However, this proposal might well be hard to implement. It would likely > require significant change to how we parse the $brooklyn expressions (if my > recollection of this code is correct). > > _*Proposal: option 2*_ > > An alternative suggested by Svet in a comment on [1]: > > Should we fix attributeWhenReady instead? It's confusing to have it > wait indefinitely on false. > Having another attribute, very similar to attributeWhenReady > complicates things even further. > > Suggest renaming attributeWhenRedy to attributeWhenTruth and > changing attributeWhenReady to wait on notNull && notEmpty. > > That sounds like a good idea - it feels much more explicit, and is very > simple to implement. > > However, it would break backwards compatibility (e.g. for those using > `attributeWhenReady("service.isUp")`. > > If we think the semantics are wrong, then we should definitely change it > while we're still on version 0.x rather than ignoring it. > > Aled > > [1] https://github.com/apache/brooklyn-server/pull/282 > [2] https://github.com/apache/brooklyn-server/blob/rel/apache- > brooklyn-0.9.0/core/src/main/java/org/apache/brooklyn/core/ > sensor/DependentConfiguration.java#L669 > >
