[Hawkular-dev] Eliminating Alerts -> Command Gateway dependency

Jay Shaughnessy jshaughn at redhat.com
Wed Jan 27 08:52:11 EST 2016 

Hawkular "glue" perhaps is the wrong term. It's the result of our 
component-centric way of thinking and how to make the components 
interact.  Really this is just the hawkular app, a consumer of the 
components. The triggers defined by Hawkular are not part of the alerts 
component, they have UI hooks built into them, knowledge of ID formats, 
and the listener needs to understand hawkular inventory api and 
semantics.   I'm not sure there is enough benefit in trying to avoid a 
Hawkular-level deployment and keep dependencies like inventory and 
command gateway in the alerts component.

I'm certainly not against getting rid of the "glue" term, though, and 
just calling the horse a horse, hawkular-listeners.jar or something similar.

On 1/27/2016 3:58 AM, Juraci Paixão Kröhling wrote:
> Forgive me if I understood the issue wrongly, but what about the
> following architecture:
>
> alerts-for-hawkular.war includes:
> AlertsEventObserver {
>       void doWhateverIsNeeded(@Observe TheEvent)
> }
>
> alerts-hawkular.jar includes:
> MessageListener {
>       Event<TheEvent> theEvent;
>       void receiveMessage() {
>         // receives the JMS message, creates a payload for the event
>         theEvent.fire(payload)
>       }
> }
>
> And alerts-for-hawkular.war would include alerts-hawkular.jar . For the
> standalone alerts.war, the alerts-hawkular just isn't included, so, the
> event is never triggered.
>
> This way, no glue is needed, and new components can plug into the
> listener without having to deal with the glue.
>
> - Juca.
>
> On 26.01.2016 20:06, Jay Shaughnessy wrote:
>> +1, I'd prefer a war and it can have rest endpoints and other ejbs.
>>
>> As for hawkular-glue, I don't know, i used that name because that is
>> what we've been calling it but I'm fine changing it to something like
>> hawkular-listeners or hawkular-bus-listeners or whatever. Need one more
>> opinion to make a decision.
>>
>> As it stands right now I'm not using the rest api but rather just using
>> jndi to get the alerts service, taking advantage of co-located deploy.
>> Is there a reason to not do it that way?
>>
>>
>> On 1/26/2016 11:32 AM, Thomas Segismont wrote:
>>> How about a single WAR named hawkular.war?
>>>
>>> Le 26/01/2016 16:26, Jiri Kremser a écrit :
>>>> Hi,
>>>>
>>>> wrt:
>>>> | 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.
>>>>
>>>> Although, it's not a rest-api, I am ok with that. So I guess the hawkular-rest-api module will depend on hawkular-glue.
>>>> Or we can create an uber (ear like) thing that will deploy the hawkular-rest.war + hawkular-glue.war.. uber-glue? :)
>>>>
>>>> btw. Do we want to use the term "hawkular-glue"? What about something more official like hawkular-{mdbs|bus-listeners|msg-something}
>>>>
>>>> Jay, I assume the module will be listening on certain events and call the rest api of particular components (or the aggregated one in the module itself), right? We may also need some kind of registry particular endpoints. Currently it's done quite naively, it assumes everything to be running on the same host:https://git.io/vzMLR
>>>>
>>>> jk
>>>>
>>>> ----- Original Message -----
>>>> | From: "Jay Shaughnessy"<jshaughn at redhat.com>
>>>> | To: "Peter Palaga"<ppalaga at redhat.com>, "Lucas Ponce"<lponce at redhat.com>, "Discussions around Hawkular development"
>>>> |<hawkular-dev at lists.jboss.org>
>>>> | Sent: Tuesday, 26 January, 2016 3:02:11 PM
>>>> | Subject: Re: [Hawkular-dev] Eliminating Alerts -> Command Gateway dependency
>>>> |
>>>> |
>>>> | 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
>>>> |
>>>> |
>>>> |
>>>> | _______________________________________________
>>>> | hawkular-dev mailing list
>>>> |hawkular-dev at lists.jboss.org
>>>> |https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>> |
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160127/2c2394be/attachment.html

More information about the hawkular-dev mailing list