CODEWITHSUNDEEP
osgiapache-felixblueprint
lostiniceland
lostiniceland

Reputation: 3789

How handle different logging solutions in OSGi (Apache Felix)

In OSGi there is a separation between the logging frontend and the actual output.

So, by using the LogService, this doesnt mean that anything is written to the console for example. This is what a LogReaderService is responsible for.

In my current runtime, I am addind org.apache.felix.log which brings a LogReaderService-Implementation which should take care of the output. But I still dont see anything on the console...despite a lot of other stuff from other bundles.

In the next step I created my own LogListener which should be called by a LogServiceReader. I just used the code from this article and debugged the Activator to see if the listener is added. Still no output.

Last I checked the Felix Properties and set felix.log.level=3 (Info) but again, no output. What I was wondering even more that I still could see a lot of DEBUG-Information despite setting the level to Info? 

16:47:46.311 [qtp1593165620-27] DEBUG org.eclipse.jetty.http.HttpParser

It seems to me that there are different logging strategies in place, which use different configuration properties. For example, after I added the pax-logging-service (which uses a classic logging approach) to my runtime I could see the output, but currently I would like to stick with felix-logging.

Can someone please explain how to disable Blueprint-Debug-Level, which I guess is causing the current output, and enable simple felix-logging via LogService? There must be a standard-console-implementation even though its not specified in the spec.

Upvotes: 4

Views: 2391

Answers (1)

lostiniceland
lostiniceland

Reputation: 3789

Thanks to Christian Schneider and Balazs Zsoldos: both comments were very helpfull.

To answer the question: I need to provide a ServiceTrackerCustomizer as shown in Balazs example here. Since I already had a ConsoleLogListener it was enough to register the listener with the TrackerCustomizer.

Since my current task is about migrating a big legacy application where I would like to introduce OSGi it makes probably more sense to go with Pax-Logging since log4j is already used in hundreds of classes which we probably wont change to LogService.

The output of Pax-Logging can be adjusted with the property org.ops4j.pax.logging.DefaultServiceLog.level set to INFO

Upvotes: 1

Related Questions