Le 21/01/2015 12:37, Heiko W.Rupp a écrit :
> +1 for alerts senders as a separate service, but like ptrans
(standalone
> application). That woud make writing/working with sender extensions easier.
Can you elaborate more? What would be the benefit of implementing them as a separate
java process as opposed to e.g. a message driven bean listening on the bus?
It sounds like I misunderstood your sentence: "Alerts on the other hand
would also initiate requests, as e.g. the notification
senders would be (micro) services on their own".
I believed you were arguing in favor of notification senders in their
own process.
If notifications senders are alone in a standalone Java application,
then sender extension model can be made easy: we make a sender base
which takes care of listening to the bus and users write simple Sender
classes (almost like in RHQ.classic).
How would standalone processes be used in a scenario where all of
Hawkular is deployed
on one hardware and inside e.g. one WildFly server?
On one physical or virtual server, it's not a problem.
Inside a Wildfly server, we could repackage the sender base and
extension as a WAR and let the container start it.
If notification extensions must be message driven beans, how can you
make use of them outside a JavaEE container?