[
https://issues.apache.org/jira/browse/BROOKLYN-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352745#comment-15352745
]
Svetoslav Neykov commented on BROOKLYN-235:
-------------------------------------------
I believe we have an OsgiBrooklynClassLoadingContext as a thread local at the
point this gets executed so should be easy to resolve the value or fail if not
found.
If this doesn’t work for some reason then option 1 sounds good. We can get the
catalog item of the entity and resolve the class against it. This has the usual
caveat that the context entity depends on who uses the value instead of where
it’s declared.
> $brooklyn:sensor ref to class name fails when class in catalog's OSGi bundle
> ----------------------------------------------------------------------------
>
> Key: BROOKLYN-235
> URL: https://issues.apache.org/jira/browse/BROOKLYN-235
> Project: Brooklyn
> Issue Type: Bug
> Reporter: Aled Sage
>
> With Brooklyn 0.9.0-SNAPSHOT...
> A customer has recently moved from using jars in ./lib/dropins to OSGi
> bundles, referenced in the catalog metadata.
> However, some of their existing catalog items fail. Below is a simplified
> version.
> {noformat}
> brooklyn.catalog:
> id: MySample
> brooklyn.libraries:
> - https://acme.com/path/to/mysample.jar
> item:
> services:
> - type: com.acme.MySample
> brooklyn.config:
> port: $brooklyn:sensor("com.acme.MySample", "sample.port")
> {noformat}
> This gives a {{ClassNotFoundException}} coming for the use of
> {{$brooklyn:sensor("com.acme.MySample", "sample.port")}}.
> The same blueprint (without the {{brooklyn.libraries}} section worked when
> the jar was instead in the dropins dir.
> ---
> The problem (I believe) is that it tries to interpret the sensor while
> initially parsing the YAML, before the catalog entry has been created, and
> the OSGi bundle has been loaded. It thus can't find the given class.
> If you change the example above to just {{$brooklyn:sensor("sample.port")}}
> then it works.
> To ensure the first example does not fail, I see a few options:
> 1. When parsing the yaml, don't fail if the class for the sensor is not found
> - let it be a runtime error instead.
> 2. Do something overly complicated (!) like a two-phase validation: an
> initial light validation of the YAML; then load the OSGi bundle; then check
> if this sensor exists; but if it doesn't then roll everything back.
> Option (2) sounds far too complicated. Should we do option (1), or are there
> better ways to fix this?
> ---
> As a (slightly related) aside, I had a conversation with another Brooklyn
> developer recently about how the semantics of
> {{$brooklyn:sensor("sample.port")}} is not intuitive. It first looks for the
> statically defined sensor on "this" entity (i.e. the entity type that it is
> defined within). But if that sensor does not exist it will just create a new
> sensor definition with the given name (of type {{Object}}, and no metadata
> like descriptions etc). This means you can use this approach to refer to a
> named sensor on another type of entity. It will just work (as long as you
> don't expect fancy type coercions).
> Should we just better document that? Or is there a cleaner way to represent
> it in YAML?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
