Aled Sage created BROOKLYN-235:
----------------------------------
Summary: $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)
