[
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 <[email protected]>
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 <[email protected]>
Date: 2017-02-28T12:44:17Z
add similar tests, including one failing, isolating the error
commit 9c38c94eeeb5a3de2a082f81546440980b1abb5c
Author: Alex Heneveld <[email protected]>
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)
