Given a common lib which is used for multiple bundles for logging purpose, (see https://github.com/xldai/test/tree/master/test-log4j2-common), there are 2 bundles which generate logging using this common lib (see https://github.com/xldai/test/tree/master/test-log4j2-bundle1 and https://github.com/xldai/test/tree/master/test-log4j2-bundle2), After build these 2 bundles and deployed them into karaf OSGi container, you can find the bundle.id/bundle.name 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 bundle.id/bundle.name can be generated from the logs.
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.
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)
Looks like only pax-logging-log4j2 does own caching. pax-logging-service and pax-logging-logback rely on impl caching instead.
I removed this caching entirely and provided an mdcSiftingAppender integration test in https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-it/src/test/java/org/ops4j/pax/logging/it/Log4J2BuiltinAppendersIntegrationTest.java that tests if same category of logger obtained from different bundles actually gives you two different loggers.