celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: celix_log as log_service-tracker?
Date Wed, 10 Sep 2014 07:06:28 GMT
Hi all,

It has been a while since I implemented the fw_log support. What I do
remember is, I modelled it in a similar fashion as Felix does. In there the
log_service is not used due to locking [1].

I don't remember the details, but with Celix for several calls this would
be a problem as well. If we do decide to update the framework logger to use
the log service, we need to look into this.

But on the other hand, after a certain point during startup, paralel to the
fw_log calls, there are framework events. For example bundle state changes.
Those events are picked up by the current log_service.
Events/log entries from before that point will never end up at the
log_service, because services can't be active yet.

So instead of investing a lot in using the log_service (with all the
locking details..) maybe we should look into expanding the number of events
sent by the framework.


2014-09-10 7:59 GMT+02:00 Marcel Offermans <marcel.offermans@luminis.eu>:

> Hello Bjoern,
> Disclaimer: I did not look at the current codebase, but from your mail a
> assume that the framework currently logs to some internal log component
> (that maybe writes to stdout or a log file) and you are asking if it is a
> good idea to redirect log information to the actual log service if it is
> available instead? If that is the question, then yes is the answer, IMHO. :)
> Greetings, Marcel
> On 09 Sep 2014, at 22:46 pm, Bjoern Petri <bjoern.petri@sundevil.de>
> wrote:
> >
> > Hi everyone,
> >
> > After replacing a bunch of printf's through fw_log calls and integrating
> the log_writer_syslog bundle, I was wondering why the fw_log isn't actually
> a serviceTracker to also use the log_service (when available). Is there any
> reason for that? Wouldn't that make sense?
> >
> > Regards,
> >  Bjoern
> >

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message