[Hawkular-dev] Eliminating Alerts -> Command Gateway dependency
Jay Shaughnessy
jshaughn at redhat.com
Tue Jan 26 09:02:11 EST 2016
Hi Peter,
Right, the issue here is that CommandEventListener was jammed into
alerts as a convenience but really should not live there. The command
gw and inventory dependencies are both due to that listener and will go
away when it moves to Hawkular proper.
As it turns out, at the moment I have just started development on
hawkular-glue-<version>.jar. I needed a place to deploy yet another
bus listener, which I am working on now. This new listener will listen
for inventory events and interact with alerting to add/remove trigger
definitions (moving trigger definition out of the UI code). This JAR is
purposed for any sort of hawkular "glue" code. I could also move
CommandEventListener into this jar. At the moment, locally, I have
this living in hawkular/modules/hawkular-api-parent/hawkular-glue and
being bundled in the hawkular-rest.war.
I have just started and have not even tried to deploy it yet, so it's up
for discussion if that is the right place. If you guys have an opinion
let me know. But basically, I can move the listener out from alerts
once this is in place.
Jay
On 1/26/2016 8:12 AM, Peter Palaga wrote:
> Hi Jay, Lucas and *,
>
> I was looking into the possibility to move all message classes [1]
> from Command Gateway to Commons. My primary motivation was to
> eliminate the dependency of Alerts on Command Gateway. After thinking
> about the impact I basically abandoned that idea.
>
> Initially, I thought, the move can be justified by the fact that those
> classes define a public API that can be hosted separately from the
> implementation. However, we have not done anything like that for any
> other component. I think that such a split would make the development
> of the command gateway (or any other component) unnecessarily
> complicated.
>
> Moreover, there is another option [2] you (Alerts guys) seem to
> foresee already:
>
> CommandEventListener can be moved to a new deployment in Hawkular.
> Hawkular Alerts should not really have knowledge about Hawkular-level
> decisions, like which possible Events to filter out or various special
> handling that needs to be performed.
>
> Hence I vote for moving CommandEventListener to Hawkular. Do you
> (Alerts guys) already have a Jira for that?
>
> Thanks,
>
> Peter
>
> [1] The message classes are generated from these schemas:
> https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/resources/schema
> plus some interfaces etc. in
> https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/java/org/hawkular/cmdgw/api
>
> [2]
> https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/CommandEventListener.java#L39-L41
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160126/32803c5f/attachment-0001.html
More information about the hawkular-dev
mailing list