[ 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 <alex.henev...@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 <alex.henev...@cloudsoftcorp.com> Date: 2017-02-28T12:44:17Z add similar tests, including one failing, isolating the error commit 9c38c94eeeb5a3de2a082f81546440980b1abb5c Author: Alex Heneveld <alex.henev...@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)