> We need defined APIs, that may result in common Java classes
that e.g.
> describe one metric or a series of metrics for a tenant
> or similar.
>...
> Yes. I don't see this as a shared service/component, but rather part of
> Hawkular-alerts. This may pull in a common java
> class that encodes how a metric looks like (see above).
FWIW: we could base these on the JSON-encoded BasicMessage [1] - Jay has
already prototyped his stuff using this, where a "metric" is JSON-encoded
(and thus can be handled across any client in any language) but yet is a
strongly-typed Java object that can be used.
[1]
https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/...
Yes, a PoC used that approach [1].
What I think (and I understand that it will be inferred from the APIs) it's the
payload type like [2].
These classes I think they should live in a common package/artifact as it can be used per
more than one component.
Or is the preferred approach is to use JSON as general payload inside the bus messages and
convert it to concrete object inside the component ?
[1]