brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-184) Entities to be auto-managed, rather than calling Entities.manage()
Date Sat, 17 Oct 2015 16:18:05 GMT

    [ https://issues.apache.org/jira/browse/BROOKLYN-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961966#comment-14961966
] 

ASF GitHub Bot commented on BROOKLYN-184:
-----------------------------------------

Github user asfgit closed the pull request at:

    https://github.com/apache/incubator-brooklyn/pull/963


> 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)

Mime
View raw message