I reproduced the problem and indeed - simple:
(getting same logger twice), when pax-logging-api is not yet started gives me two instances of org.ops4j.pax.logging.slf4j.Slf4jLogger, but only one is cached in (now global) org.ops4j.pax.logging.internal.Activator#m_loggers.
I changed this org.ops4j.pax.logging.internal.Activator#m_loggers map to ... list and it works fine Both the above loggers have their m_delegate replaced when pax-logging-api starts.
What's more - I added special unit test (in pax-logging 1.11.x+) to prove this. But I can also backport the fix to pax-logging 1.10.x.
What's even more, here's resulting behavior:
when pax-logging-api is not yet started:
all bundles starting "earlier" can already use any logging facade provided by (not even started) pax-logging-api - pax-logging-api needs to be at least resolved, otherwise other bundles would not be resolved too.
all obtained loggers use underlying m_delegate set to DefaultServiceLog
when pax-logging-api finally starts:
all bundles added to (now a list) org.ops4j.pax.logging.internal.Activator#m_loggers have their org.ops4j.pax.logging.PaxLoggingManagerAwareLogger#setPaxLoggingManager() method called and underlying m_delegate switched from DefaultServiceLog to TrackingLogger obtained from org.ops4j.pax.logging.OSGIPaxLoggingManager#getLogger() and org.ops4j.pax.logging.internal.Activator#m_loggers is cleared! because we no longer need to replace underlying m_delegate
these underlying TrackingLoggers will switch back and forth between DefaultServiceLog and actual PaxLoggerImpl when pax-logging-log4j1/pax-logging-log4j2/pax-logging-logback bundles are restarted OR refreshed
when pax-logging-api stops
org.ops4j.pax.logging.internal.Activator#m_loggers is already empty, so nothing is done in this list - however org.ops4j.pax.logging.OSGIPaxLoggingManager#m_loggers is not empty - it contains ALL tracking loggers for all facades. These loggers have their m_delegate switched back to DefaultServiceLog
loggers do NOT switch again to TrackingLoggers when pax-logging-api starts again - the above COULD be improved if org.ops4j.pax.logging.OSGIPaxLoggingManager#m_loggers was static, but:
I think stopping pax-logging-api is not something that should be done frequently
loggers would still be disconnected when pax-logging-api is REFRESHED - but this would lead to refresh of almost everything... So we could consider preserving the map of TrackingLoggers in the future
loggers switch to proper m_delegate when pax-logging-log4j1/pax-logging-log4j2/pax-logging-logback restarts/refreshes
For 1.10.x each facade has own m_loggers cache. and I changed it from String→Logger to String→List<Logger> map, so we're sure that all loggers obtained before pax-logging-api starts are switched from DefaultServiceLog to TrackingLogger.