[
https://issues.apache.org/jira/browse/BROOKLYN-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887951#comment-15887951
]
Alex Heneveld commented on BROOKLYN-445:
----------------------------------------
A simple fix is to prevent the call to set the catalog item ID from a context
thread. All tests seem to pass - see
https://github.com/apache/brooklyn-server/pull/573 .
If this is problematic we will have to introduce a separate "searchable catalog
item IDs" field, or, probably better, introduce and use
`catalogItemIdsForSearching` which could be a list, including caller context.
(This may be related to an idea for a `catalogBomId` on catalog items, so we
know which BOM defines things, and can resolve unversioned references to the
same BOM where an item is defined, so e.g. if my-cluster:1.0 refers to my-node,
with my-cluster and my-node in the same bundle/bom, then my-node is resolved to
the local bom as my-cluster, rather than the latest my-node.)
> 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)
