[
https://issues.apache.org/jira/browse/BROOKLYN-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961954#comment-14961954
]
ASF GitHub Bot commented on BROOKLYN-184:
-----------------------------------------
Github user hzbarcea commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/963#issuecomment-148927318
Looks good, test passed. Reviewed. Merging.
> 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)
