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

Hi Jay, nice to see that the task is being worked on, does it have a Jira that I could watch to get notified about the progress? Thanks, -- P On 2016-01-26 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&quot;&lt;jshaughn(a)redhat.com&gt; >>> | To: "Peter Palaga&quot;&lt;ppalaga(a)redhat.com&gt;, "Lucas >>> Ponce&quot;&lt;lponce(a)redhat.com&gt;, "Discussions around Hawkular development" >>> |&lt;hawkular-dev(a)lists.jboss.org&gt; >>> | 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(a)lists.jboss.org >>> |https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> | >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev >