[jira] [Commented] (BROOKLYN-445) Search path and meaning of catalogItemId is overloaded

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

Github user asfgit closed the pull request at:

    https://github.com/apache/brooklyn-server/pull/573


> Search path and meaning of catalogItemId is overloaded
> ------------------------------------------------------
>
>                 Key: BROOKLYN-445
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-445
>             Project: Brooklyn
>          Issue Type: Bug
>    Affects Versions: 0.10.0
>            Reporter: Alex Heneveld
>
> We use catalogItemId on a spec or BrooklynObject for two things:
> (1) Record the catalog item that was defined to create an item
> (2) Find the search path to use when looking up resources and/or creating other specs
> Most of the time these two are the same, e.g. an entity comes from catalog item `cassandra-node:1.0` and the implementation should use the bundles defined against that to resolve scripts etc.  The catalogItemId is the only record of the catalog-entry that was used to define the entity; the entity spec reduces it to the java type which might tell you one bundle but won't tell you of other library entries from the definition.
> However in some cases we seem to want the context catalogItemId to be inherited, e.g. we reference a stock type like `VanillaServer` as a child but supply config pointing at scripts/images in the parent's bundle.  This is currently achieved by a line in AbstractBrooklynObjectSpec's constructor which sets the catalogItemId from the thread context entity's catalog item ID.  However there are a couple problems with this:
> (A) We can't tell if the `catalogItemId` is the definition of an entity (it usually is, but sometimes might be inherited), so we can't tell what was used to create an entity
> (B) A child's search behaviour differs depending whether that child comes from another catalogItemId (which will overwrite the inherited context catalogItemId) or a stock item (e.g. a java type is passed to the spec constructor)
> (C) When setting the EntityDynamicType we can't tell whether to clear the config keys set there; in InternalEntityFactory.addSpecParameters we need to know whether the spec extends the Java type defining it (in which case CAMP code in BasicSpecParameter.initializeSpecWithExplicitParameters has filtered out those keys which are not type-definition inheritable and set the spec.parameters, so the EntityDynamicType's keys should be cleared) or not (in which case spec.parameters won't normally be set and EDT.configKeys should not be cleared).  Currently it checks whether there is a catalogItemId, and assume it is set iff the spec is extending (former case); this assumption fails if catalogItemId is inherited from context.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)