OSGi and logback configuration
There are issues with logging in an OSGi environment. There are many official ways to do this, some of which requires re-routing OSGi logging services and traditional services through another logger and configuring the logger implementation. All of that can be done, but in the end you have to configure your logger. I was using spring dm but was having problems getting logback to configure correctly and I was therefore receiving too many logging messages that I could not control.
Here are some links to different blogs that describe what to do. However, none of them worked for me:
No matter what, I could not get the logback.xml to configure correctly, even in a fragment host. Well, I pulled out the logback source and noticed that the the class loader being used to find the logback resource is actually the ContextLoader class which is in the classic bundle. Hence, attaching the fragment to the core bundle did not work consistently for me even though the actual loading occurs from a class in the core bundle itself (the Loader class). To get the config to be recognized I had to ensure that the bundle classpath was set to “.” (or the right path depending on where you stick the logback.xml file) and use the right symbolic name. Since I use the logback bundle from springsource enterprise repository, I needed a manifest.mf that looked like:
You’ll need an execution environment that works for you. This worked for my scenario and I was finally able to control logging in spring dm with logback.
It would be nice to have a configuration service defined for logback, much like the JMX configuration bean that is provided in logback today. However, you’ll need to think about the design and functionality that is important for that and perhaps there is an OSGi configuration admin-to-JMX bridge somewhere.