7:12 a.m.
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...
plus some interfaces etc. in
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
[2]
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
8:02 a.m.
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...
plus some interfaces etc. in
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
[2]
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
9:26 a.m.
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(a)redhat.com>
| To: "Peter Palaga" <ppalaga(a)redhat.com>, "Lucas Ponce"
<lponce(a)redhat.com>, "Discussions around Hawkular development"
| <hawkular-dev(a)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...
| plus some interfaces etc. in
|
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
|
| [2]
|
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
|
|
|
| _______________________________________________
| hawkular-dev mailing list
| hawkular-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/hawkular-dev
|
10:32 a.m.
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(a)redhat.com>
| To: "Peter Palaga" <ppalaga(a)redhat.com>, "Lucas Ponce"
<lponce(a)redhat.com>, "Discussions around Hawkular development"
| <hawkular-dev(a)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...
| plus some interfaces etc. in
|
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
|
| [2]
|
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
|
|
|
| _______________________________________________
| 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
1:06 p.m.
+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(a)redhat.com>
> | To: "Peter Palaga" <ppalaga(a)redhat.com>, "Lucas Ponce"
<lponce(a)redhat.com>, "Discussions around Hawkular development"
> | <hawkular-dev(a)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...
> | plus some interfaces etc. in
> |
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
> |
> | [2]
> |
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
> |
> |
> |
> | _______________________________________________
> | 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
2:58 a.m.
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(a)redhat.com>
>> | To: "Peter Palaga"<ppalaga(a)redhat.com>, "Lucas
Ponce"<lponce(a)redhat.com>, "Discussions around Hawkular development"
>> |<hawkular-dev(a)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(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
7:52 a.m.
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(a)redhat.com>
>>> | To: "Peter Palaga"<ppalaga(a)redhat.com>, "Lucas
Ponce"<lponce(a)redhat.com>, "Discussions around Hawkular development"
>>> |<hawkular-dev(a)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(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
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:31 a.m.
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(a)redhat.com>
>> | To: "Peter Palaga"<ppalaga(a)redhat.com>, "Lucas
Ponce"<lponce(a)redhat.com>, "Discussions around Hawkular development"
>> |<hawkular-dev(a)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(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
7:32 a.m.
Hawkular-922
On 1/27/2016 4:31 AM, Peter Palaga wrote:
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(a)redhat.com>
>>> | To: "Peter Palaga"<ppalaga(a)redhat.com>, "Lucas
>>> Ponce"<lponce(a)redhat.com>, "Discussions around Hawkular
development"
>>> |<hawkular-dev(a)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(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
>
3257
days inactive
3258
days old
8 comments
5 participants
participants (5)
-
Jay Shaughnessy -
Jiri Kremser -
Juraci Paixão Kröhling -
Peter Palaga -
Thomas Segismont