brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-184) Entities to be auto-managed, rather than calling Entities.manage()
Date Thu, 15 Oct 2015 19:59:05 GMT


ASF GitHub Bot commented on BROOKLYN-184:

Github user aledsage commented on a diff in the pull request:
    --- Diff: core/src/main/java/org/apache/brooklyn/enricher/stock/ ---
    @@ -520,6 +522,10 @@ public B from(Entity val) {
                 this.fromEntity = checkNotNull(val);
                 return self();
    +        public B from(Task<? extends Entity> val) {
    --- End diff --
    Note that I added in this PR the seemingly unrelated "Enrichers: support producer as Task
for deferred supplier" so that I could re-write some of the code to use `EntitySpec`, rather
than the previous way of constructing two entities and then calling `manage()`.

> Entities to be auto-managed, rather than calling Entities.manage()
> ------------------------------------------------------------------
>                 Key: BROOKLYN-184
>                 URL:
>             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.
> 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
> 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

View raw message