<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Calibri">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.<br>
<br>
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.<br>
</font><br>
<div class="moz-cite-prefix">On 1/27/2016 3:58 AM, Juraci Paixão
Kröhling wrote:<br>
</div>
<blockquote cite="mid:56A886B2.3070502@redhat.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">
+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:
</pre>
<blockquote type="cite">
<pre wrap="">How about a single WAR named hawkular.war?
Le 26/01/2016 16:26, Jiri Kremser a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">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:<a class="moz-txt-link-freetext" href="https://git.io/vzMLR">https://git.io/vzMLR</a>
jk
----- Original Message -----
| From: "Jay Shaughnessy"<a class="moz-txt-link-rfc2396E" href="mailto:jshaughn@redhat.com"><jshaughn@redhat.com></a>
| To: "Peter Palaga"<a class="moz-txt-link-rfc2396E" href="mailto:ppalaga@redhat.com"><ppalaga@redhat.com></a>, "Lucas Ponce"<a class="moz-txt-link-rfc2396E" href="mailto:lponce@redhat.com"><lponce@redhat.com></a>, "Discussions around Hawkular development"
|<a class="moz-txt-link-rfc2396E" href="mailto:hawkular-dev@lists.jboss.org"><hawkular-dev@lists.jboss.org></a>
| 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:
|<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>
|
| [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>
|
|
|
| _______________________________________________
| hawkular-dev mailing list
|<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
|<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
|
_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>