felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Logging in Karaf/OSGI
Date Thu, 08 Apr 2010 13:09:09 GMT
Thanks a lot for your answer Guillaume!

I will definitely have a look at PaxLoggingService - it seems to be
more competent than I had realised. Two things I would like to achieve
is to have the ServiceReference passed on all the way to the
LogService (automatically if possible but maybe that's not possible)
but also to be able to set  other values in the MDC (like the
service.PID) and have the possibility to list log entries for a
specific service.PID.

If you have any clues I'd be thankful. I'm also using iPOJO if that
might open some possibilities regarding this matter.

Thanks,

/Bengt


2010/4/8 Guillaume Nodet <gnodet@gmail.com>:
> I don't think we'd have any issues with improving Karaf ;-)
>
> I do understand the need for more focused logging, we've had a similar
> request to be
> able to log to different files wrt to the "feature" logging.   So I'm
> personnaly opened to any improvement,
> but getting rid of ops4j pax logging service is not really an option in my
> mind, unless it is replaced by something
> equivalent (which can centralize calls to multiple logging libraries).
>
> If you really want to be able to track which bundle is logging, the only way
> that comes to my mind is
> to use the OSGi Log Service.  As you say, however, it's use is not really
> easy.  I guess one way would
> be to wrap it in a more friendly class / api.   But I'd say that what pax
> logging already provides that in its
> native api.
>
> Take a look at the org.ops4j.pax.logging.OSGIPaxLoggingManager.  It is quite
> easy to use:
>
>  OSGIPaxLoggingManager manager = new OSGIPaxLoggingManager(bundleContext);
>  PaxLogger logger = manager.getLogger(category, fqcn);
>
> It will track the bundle logging events.
>
> For the MDC thingy, pax logging also provides an MDC support:
>   PaxLoggingService service = manager.getPaxLoggingService();
>   service.getContext().put(key, val);
>
> Hopes this helps.
>
> On Thu, Apr 8, 2010 at 07:32, Bengt Rodehav <bengt@rodehav.com> wrote:
>
>> I'm in the process of building an integration platform using Karaf +
>> Camel. Part of this includes providing the user with log information
>> per installed service (OSGI service). This doesn't seem to be easily
>> accomplished.
>>
>> Karaf uses log4j with a special appender that routes all logging to
>> the OSGI LogService. However, this way the OSGI LogService does not
>> get any information regarding the source OSGI service which is
>> unfortunate since I intended to use the OSGI LogReaderService to show
>> the relevant log entries (for the specified service) in the user
>> interface.
>>
>> I've also tried to use the OSGI LogService directly. Although this
>> works in principal, it is not a very convenient way of logging. I
>> would like to transparently log the same way without having to care
>> about passing the ServiceRefence of the current service to the
>> LogService. Besides, it would be even better to separate the logs not
>> on ServiceReference (which will be recreated each time a service stops
>> and restarts) but on the configuration PID which is consistent over
>> service restarts. Also, when logging using the LogService I seem to
>> get all log entries duplicated when looking at the log using the
>> LogReaderService.
>>
>> My question is therefore: Are there any plans to replace/improve the
>> logging in Karaf? I've been looking at the slf4j/logback combination
>> and it looks like a much better fit for OSGI. In particular there is a
>> concept called "Mapped Diagnostic Context"
>> (http://logback.qos.ch/manual/mdc.html) that seems to make it possible
>> to add contextual information to the logging system. E g one can
>> imagine that the ServiceReference (and possibly the service.pid) could
>> be added to the context and automatically be logged.
>>
>>
>> Best regards,
>>
>> /Bengt
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message