Fantastic! Worked first time :-) Thanks Aled
On 29 September 2015 at 10:45, Aled Sage <[email protected]> wrote: > Hi Richard, > > To do this from YAML, you can use a "transformer" enricher. Here's a simple > test I wrote, which you can adapt to your use-case: > > services: > - type: org.apache.brooklyn.core.test.entity.TestEntity > id: childid > brooklyn.config: > jenkins.port: 1234 > brooklyn.initializers: > - type: org.apache.brooklyn.core.sensor.StaticSensor > brooklyn.config: > name: host.name > static.value: myhostname > brooklyn.enrichers: > - enricherType: org.apache.brooklyn.enricher.stock.Transformer > brooklyn.config: > enricher.producer: $brooklyn:component("this" ,"") > enricher.sourceSensor: $brooklyn:sensor("host.name") > enricher.targetSensor: $brooklyn:sensor("main.uri") > enricher.targetValue: $brooklyn:formatString("http://%s:%s/";, > $brooklyn:component("childid").attributeWhenReady("host.name"), > $brooklyn:component("childid").config("jenkins.port")) > > The transformer executes every time the source sensor is changed (in this > case "host.name"). In this case, the "jenkins.port" is already set so it can > resolve the value immediately. > > If jenkins.port was not available, the formatString would not yet be > resolvable. It would retry next time "host.name" changed. > > Aled > > p.s. for your example, clearly you wouldn't have the StaticSensor for > "host.name" - you'd rely on that being set automatically when the machine > was obtained. > > > > On 29/09/2015 07:43, Richard Downer wrote: >> >> Hi Svet, >> >> On 29 September 2015 at 07:38, Svetoslav Neykov >> <[email protected]> wrote: >>> >>> Attributes resolve values at set time, whereas config keys resolve at get >>> time - can't have a future as the value of an attribute. I would approach >>> this with some kind of transformer which monitors the dependent values and >>> updates the target sensor. No out of the box solution to be used in YAML >>> though. >> >> You've guessed what I was trying to do - express this as a pure-YAML >> blueprint. Oh well! Something for the feature request list. >> >> Thanks for your response. >> >> Richard. > >
