Aled Sage created BROOKLYN-184:
----------------------------------
Summary: Entities to be auto-managed, rather than calling
Entities.manage()
Key: BROOKLYN-184
URL: https://issues.apache.org/jira/browse/BROOKLYN-184
Project: Brooklyn
Issue Type: Improvement
Affects Versions: 0.8.0
Reporter: Aled Sage
As per the dev@brooklyn e-mail thread entitled "PROPOSAL] entities always
managed when instantiated", entities should be automatically managed, rather
than us having an explicit {{Entities.manage()}} method.
http://mail-archives.us.apache.org/mod_mbox/incubator-brooklyn-dev/201509.mbox/%3C55FFE916.7030103%40gmail.com%3E
h2. Proposal
When an entity is instantiated (which always involves setting its parent,
unless it is a top-level app) then the entity will immediately be managed.
The call to {{Entities.manage()}} will be deprecated. Its implementation will
check that the entity is managed - if it is not, there will be a log.warn about
the deprecated behaviour and the entity will be explicitly managed (for
backwards compatibility).
We will deprecate the {{NonDeploymentManagementContext}} (which is only used
internally), and will delete it when {{Entities.manage()}} is deleted.
h2. Historic reason
The reason we didn't just automatically manage an entity when it is constructed
is mostly historic.
There was a perceived use-case that one might instantiate an entity, explicitly
set config on it, and only then manage it. However, everywhere (I believe) we
set the entity's configuration on the {{EntitySpec}} before instantiating it -
that is certainly the case for YAML-based entities! The only time we couldn't
do that is if we have two entities (X and Y) that require config values that
depend on each other - e.g. X wants a config value of an attributeWhenReady on
Y, and vice versa. However, that (contrived?) use-case does not justify the
confusion of the explicit manage. We could handle such use-cases by writing
Java code in the entity, if we come across them.
h2. Current code
Currently, an entity only becomes "managed" (i.e. visible to other entities)
when it or its parent/grandparent/etc is explicitly managed.
This leads to two very different ways of dealing with entities:
* For child entities instantiated in an entity's {{init()}}, one does not
have to call an explicit {{manage()}}.
This is because those children will piggie-back on the parent entity
becoming managed at some point after it has been initialised.
* For top-level apps (e.g. referenced via YAML), the code that reads
the blueprint will automatically do the {{manage()}} so folk don't need
to worry about it.
* For child entities instantiated after the parent is managed, then
the parent must explicitly call {{manage().}}
For example, when a cluster grows (i.e. adds additional child
entities), then that code explicitly calls {{manage().}}
There is overly complicated code for handling entities that have been
instantiated but that are not yet managed. The entity has a
{{NonDeploymentManagementContext}}, which allows some operations and forbids
others; that is swapped for the real {{ManagementContext}} when the entity
becomes managed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
