[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=15887941#comment-15887941 ] 

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

GitHub user ahgittin opened a pull request:

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

    Do not runtime-inherit catalog item

    fixes https://issues.apache.org/jira/browse/BROOKLYN-445 and failing tests included here
    
    means catalog BOMs should be written such that any entity/policy/etc which wants to access resources in the bundle is defined as its own item

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server do-not-inherit-catalog-item-id

Alternatively you can review and apply these changes as the patch at:

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #573
    
----
commit d7cbaeed46d7fedf8e49df015baa812352060f45
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-02-28T12:43:14Z

    add original failing test from @sjcorbett
    
    for failure to set inherited config keys - https://issues.apache.org/jira/browse/BROOKLYN-445

commit edaf05441ee46d05e4479a79aee055e6cbfe1237
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-02-28T12:44:17Z

    add similar tests, including one failing, isolating the error

commit 9c38c94eeeb5a3de2a082f81546440980b1abb5c
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-02-28T12:55:24Z

    apply the fix for previous failing tests and https://issues.apache.org/jira/browse/BROOKLYN-445
    
    do not use a context catalog item id.  this is a significant change and release notes should be updated,
    but it doesn't seem to break any of our tests; presumably most catalog items are already refactoring
    so each item is declared as its own item.

----


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