[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