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?
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).