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"<jshaughn@redhat.com>
| To: "Peter Palaga"<ppalaga@redhat.com>, "Lucas Ponce"<lponce@redhat.com>, "Discussions around Hawkular development"
|<hawkular-dev@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@lists.jboss.org
|https://lists.jboss.org/mailman/listinfo/hawkular-dev
|
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev