4

I am working with OSGi and declarative services (DS) and am currently thinking of how to handle the logging properly. Since i'm working with DS anyways, it seems natural to use the LogService specified by the OSGi service compendium as a mandatory service reference. I have been reading a lot on the net at ekkes corner and nogunners's blog, but something is still unclear to me:

How do I make a proper distinction of different service components (or different service component instances when using factored components)?

If I look at nogunners implementation of the LogListener using Logback, he uses the Bundle-Id form the bundlecontext to differentiate those. Ok so far. But how would I differentiate the service components? The LogService object contains a reference to the BundleContext naturally, but (looking into the LogService interface) a ServiceReference must be given by the user (the one who actually logs something) itself? This seems fragile to me. Why can't the framework deliver this as it delivers the BundleContext?

And while I'm at it, why does the OSGi spec use the verbose logger.log(LogService.LOG_INFO,...) instead of the quasi-standard logger.info(...), logger.warn(..) etc.? Is there some specific reason for that?

Cœur
  • 37,241
  • 25
  • 195
  • 267
benjamin
  • 1,066
  • 11
  • 22

1 Answers1

5

There is no standard way to log the component id, you will have to embed this in the message.

The OSGi log service is 14 years old ... It was decided not to upgrade it because there were already so (too) many logging systems around.

Look at http://team.ops4j.org/wiki/display/paxlogging/Pax+Logging, they integrate popular loggers with OSGi (both ways).

Peter Kriens
  • 15,196
  • 1
  • 37
  • 55
  • Thanks for the quick answer, I'll have a closer look at Pax Logging. But since I really want precise Component differentiation, not only embedded in the message, I'll probably go for an own implementation... – benjamin May 11 '12 at 09:18
  • Some clarification: Using a ServiceFactory for the logging service makes it possible to give different service instances to different bundles and thus keep track of their BundleContext.I was supecting that this would be possible for the ComponentContext as well. Bad news is: it is not, because the framework is allowed to cache service instances and reuse them when the same bundle requests the service. As a consequence, you can't distinct different services from one bundle. This is imho bad design. See http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceFactory.html – benjamin May 11 '12 at 11:18
  • I strongly endorse the Pax-Logging recommendation. I use it with SLF4J. If you use Apache-Karaf, then Pax-Logging comes pre-bundled. – Chris Dolan May 12 '12 at 15:39