public static class BrooklynEntityMirrorImpl.RemoteEffector<T> extends EffectorBody<T>
| Modifier and Type | Field and Description |
|---|---|
java.lang.String |
remoteEffectorName |
com.google.common.base.Function<HttpToolResponse,T> |
resultParser |
| Constructor and Description |
|---|
BrooklynEntityMirrorImpl.RemoteEffector(java.lang.String remoteEffectorName,
com.google.common.base.Function<HttpToolResponse,T> resultParser)
creates an effector implementation which POSTs to a remote effector endpoint, optionally converting
the byte[] response (if resultParser is null then null is returned)
|
| Modifier and Type | Method and Description |
|---|---|
T |
call(ConfigBag parameters)
Does the work of the effector, either in place, or (better) by building up
subtasks, which can by added using
DynamicTasks methods
(and various convenience methods which do that automatically; see subclasses of EffectorBody
for more info on usage; or see DynamicSequentialTask for details of the threading model
by which added tasks are placed in a secondary thread) |
public final java.lang.String remoteEffectorName
public final com.google.common.base.Function<HttpToolResponse,T> resultParser
public BrooklynEntityMirrorImpl.RemoteEffector(java.lang.String remoteEffectorName,
@Nullable
com.google.common.base.Function<HttpToolResponse,T> resultParser)
public T call(ConfigBag parameters)
EffectorBodyDynamicTasks methods
(and various convenience methods which do that automatically; see subclasses of EffectorBody
for more info on usage; or see DynamicSequentialTask for details of the threading model
by which added tasks are placed in a secondary thread)
The associated entity can be accessed through the EffectorBody.entity() method.
call in class EffectorBody<T>