@Beta public interface SpecialBrooklynObjectConstructor
SpecialBrooklynObjectConstructor.Config.SPECIAL_CONSTRUCTORconfig key in the spec pointing to the class; it will be instantiated and
#create(Class, AbstractBrooklynObjectSpec)invoked to create the class. The type of course must be consistent with the spec.
This entire mechanism is beta; it is introduced for a few special cases where some type of dynamicism is currently required.
In most cases the
AbstractBrooklynObjectSpec should correspond directly to the object created.
Some use cases are:
See implementations of this interface.
Note that the caller may typically do additional configuration on the resulting object, such as setting a catalog item ID etc. That behaviour may merit adjustment and is subject to change.
Where this returns an existing item we must be VERY careful around *unmanaging*, both when this reference is unmanaged (but the original is still in use) and when the target is unmanaged (but this reference is still in use).
Some possible improvements to the simple approach here are:
Entityinterface pointing at the target. (This would work fine for sensors/effectors but it would fail any java type checks or casts. We could switch to a brooklyn-managed type system, which would also allow for explicit yaml inheritance, but that's not a small task.)
Locationtype, on a case-by-case basis, where the lifecycle is as normal, and the logic for initializing and delegating is done in the init. (Possibly this is better than the current implementation!? It is certainly simpler than allowing multiple links to existing items, and would be feasible in many cases, e.g. a `same-machine-as` type (assuming we made SshMachineEntity an interface); but it would not allow choosing an entity type smartly based on location.)
|Modifier and Type||Interface and Description|