Alex Heneveld created BROOKLYN-445:
--------------------------------------
Summary: 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)
