[jira] [Commented] (BROOKLYN-235) $brooklyn:sensor ref to class name fails when class in catalog's OSGi bundle

["Svetoslav Neykov (JIRA)" <ji...@apache.org>]

    [ 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)