<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Calibri">Hi Peter,<br>
<br>
Right, the issue here is that </font><font face="Calibri">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Jay<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 1/26/2016 8:12 AM, Peter Palaga
wrote:<br>
</div>
<blockquote cite="mid:56A770AF.5000305@redhat.com" type="cite">Hi
Jay, Lucas and *,
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Moreover, there is another option [2] you (Alerts guys) seem to
foresee already:
<br>
<br>
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.
<br>
<br>
Hence I vote for moving CommandEventListener to Hawkular. Do you
(Alerts guys) already have a Jira for that?
<br>
<br>
Thanks,
<br>
<br>
Peter
<br>
<br>
[1] The message classes are generated from these schemas:
<a class="moz-txt-link-freetext" href="https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/resources/schema">https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/resources/schema</a>
plus some interfaces etc. in
<a class="moz-txt-link-freetext" href="https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/java/org/hawkular/cmdgw/api">https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/java/org/hawkular/cmdgw/api</a><br>
<br>
[2]
<a class="moz-txt-link-freetext" href="https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/CommandEventListener.java#L39-L41">https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/CommandEventListener.java#L39-L41</a><br>
<br>
</blockquote>
<br>
</body>
</html>