Hi Jean-Baptiste,

I come back with a more detailed presentation of my use case. I'm
interested what's your advice.
In a Karaf instance, I have deployed lots of Apache Camel contexts. Each
context is deployed in Karaf as a bundle. Each route from an Apache Camel
context, has an onException clause, which would be entered in case of any
exception that is thrown. In this onException clause, I have called a
processor called loggingProcessor. In this processor I can get the case
when there was an exception using:

exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Exception.class)
.

Now, having all this framework set up, I'm interested to know how I can get
the behavior mentioned above. I'll review it here a bit.
I have a different process running in a different Java Virtual Machine (can
be on the same host or on a different one, both cases). I want to be able
to be notified in this different JVM in real time about exceptions which
enter the above mentioned processor.

1. As a solution to this scenario I thought about registering an MBean
service which can notify the registered processes via a socket, or via RMI
(I'm not very familliar with JMX, but I hope this is possible using MXBean).
2. On other hand, I saw that Karaf Decanter tries to offer some of this
behavior.

Point 1 seems to me very simple because the filtering can be made really
easy.
I don't have an idea about Karaf Decanter yet.

Can you give me some advice? How do you think I should go for this?

Thanks,
Andrei M.

On Tue, Sep 28, 2021 at 12:24 PM Jean-Baptiste Onofré <[email protected]>
wrote:

> JMX is just a "frontend" to MBean/services provided by a bundle.
>
> So, I would create a bundle providing health check service and exposed
> as a MBean (like this:
>
> https://github.com/apache/karaf/tree/main/examples/karaf-mbean-example
>
> Regards
> JB
>
> On 28/09/2021 11:12, Andrei Petru Mura wrote:
> > Ok. I got that a health service would be a good option. But would this
> > service have to be deployed as a bundle or can I install it via JMX?
> > I ask this because I would try to avoid as much as possible "static"
> > configuration.
> >
> > Thanks,
> > Andrei
> >
> > On Tue, Sep 28, 2021 at 12:05 PM Jean-Baptiste Onofré <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     OK, if it's for testing purpose why not, but I think we already have
> >     quite similar existing stuff for that (maybe Cave Deployer, or
> >     implementing simple health check service).
> >
> >     NB: "gaz plant" means super complex stuff for simple purpose ;)
> >
> >     Regards
> >     JB
> >
> >     On 28/09/2021 10:05, Andrei Petru Mura wrote:
> >      > Hmmm...
> >      > I intend to do this for testing purposes only. This means that I
> >     want to
> >      > check that new upgrades, features, updates, etc are fully working
> >     for
> >      > the current applications. In order to check this, I want to test
> >     my prod
> >      > apps in a dev environment.
> >      > Having all this said, I would go to talk on your points a bit.
> >      >
> >      > 1. I would go for log checking because I need it to be as quick as
> >      > possible. I mean if it's real time, is great. I think about
> >     adding one
> >      > main log listener at startup and when some new log listeners are
> >     needed,
> >      > this log listener will delegate the logs according to some
> filtering
> >      > rules. Do you think this is still not a good option?
> >      >
> >      > 2. How can I record MyLogListener as a service via JMX? In karaf
> >      > 4.3.3, org.apache.karaf.service.core.ServicesMBean has only
> >     getService.
> >      > Do I have to go via programmatically adding some ops4j.pax.logging
> >      > configuration? Some hints on this would be helpful.
> >      >
> >      > N.B. I'm not sure what a "gaz plant" is. You can detail a bit on
> >     this :)
> >      >
> >      > Thanks,
> >      > Andrei
> >      >
> >      > On Tue, Sep 28, 2021 at 10:37 AM Jean-Baptiste Onofré
> >     <[email protected] <mailto:[email protected]>
> >      > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >      >
> >      >     Hi,
> >      >
> >      >     1. are you sure it's a good idea to check the log ? Why not
> >     just having
> >      >     a health check service in your app bundles ?
> >      >
> >      >     2. You can register a PaxAppender like this:
> >      >
> >      >
> >      >     public class MyLogListener implements PaxAppender {
> >      >
> >      >              public void doAppend(PaxLoggingEvent event) {
> >      >                      // ...
> >      >              }
> >      >
> >      >     }
> >      >
> >      >     And register this PaxAppender as a service.
> >      >
> >      >     NB: according to the messages you sent, I afraid you are
> >     creating a
> >      >     "gaz
> >      >     plant". I would recommend to take time to evaluate what you
> >     need and
> >      >     your design. If you need, I can help you on this.
> >      >
> >      >     Regards
> >      >     JB
> >      >
> >      >     On 28/09/2021 09:29, Andrei Petru Mura wrote:
> >      >      > In my scenario, I try to deploy some bundles in my Karaf
> >     server,
> >      >     check
> >      >      > the status that everything is working, make some work with
> the
> >      >      > successfully deployed bundles and undeploy them. In order
> >     to get the
> >      >      > status of work done, I would need a log listener for
> specific
> >      >     bundles.
> >      >      > I see the ideal case to be able to register via JMX a log
> >      >     listener as I
> >      >      > like and remove it via JMX as I like. Is this possible?
> >      >      > If yes, can you give me some hints, please?
> >      >      > If not, what other approach would you recommend to me?
> >      >      > N.B. Please note that I need to do this programmatically.
> >     Adding
> >      >      > appenders in ${karaf.home}/etc/org.ops4j.pax.logging.cfg
> >     wouldn't
> >      >     be a
> >      >      > solution for me.
> >      >      >
> >      >      > Thanks,
> >      >      > Andrei
> >      >
> >
>

Reply via email to