Incorrect bundle names in the logs in case of the logs come from embeded lib


Given a common lib which is used for multiple bundles for logging purpose, (see, there are 2 bundles which generate logging using this common lib (see and, After build these 2 bundles and deployed them into karaf OSGi container, you can find the in the logs is always come from the bundle which first got deployed.

After some debugging, I found that an ConcurrentMap<String, PaxLoggerImpl> is used to store/get the Logger for specific class in the PaxLoggingServiceImpl of the the pax-logging-log4j2-1.10.1 bundle, it only store the PaxLoggerImpl which first deployed for the same key.

I made a patched pax-logging-log4j2-1.10.1 bundle with these changes, and then the correct can be generated from the logs.




Grzegorz Grzybek
March 12, 2019, 10:32 AM

The patch is not correct. Rather org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl#m_loggers should be indexed using logger name and bundle symbolic name combined. This patch simply overrides previous logger.

Grzegorz Grzybek
March 12, 2019, 11:14 AM

What's even worse is that if you completely uninstall first bundle that grabbed given logger, it is still used (until you refresh pax-logging bundle)

Grzegorz Grzybek
April 30, 2019, 4:52 PM

Looks like only pax-logging-log4j2 does own caching. pax-logging-service and pax-logging-logback rely on impl caching instead.

Grzegorz Grzybek
June 3, 2019, 3:27 PM

I removed this caching entirely and provided an mdcSiftingAppender integration test in that tests if same category of logger obtained from different bundles actually gives you two different loggers.


Grzegorz Grzybek


Xilai Dai

Fix versions




Affects versions