Pax Logging loses track of loggers (because of generics refactoring)

Environment

None

Activity

Show:
Grzegorz Grzybek
January 2, 2020, 4:31 PM

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:

  1. 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

  2. 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

  3. 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

Conclusion:

  • 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

Grzegorz Grzybek
January 3, 2020, 8:48 AM

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.

Assignee

Grzegorz Grzybek

Reporter

Grzegorz Grzybek

Fix versions

Labels

None

Affects versions

Priority

Major
Configure