Improve OSGi-friendliness of Log4j Core

[ppkarwasz]

While Log4j Core does support OSGi deployments, it is less OSGi-friendly than Logback.

As an indication of missing features, the PAX Logging project must override 6 classes from log4j-core, but only 1 class from Logback.

PAX Logging maintainer @grgrzybek, provided an extensive explanation of each override in this long answer. We should probably evaluate the possibility of enhancing some of those classes.

[grgrzybek]

In a world with 48-hour day, I'd be super happy to fix all issues related to OSGi. However I also maintain Pax Web and there's even bigger effort to implement the biggest Java mistake ever and unnecessary task - migration from javax.servlet to jakarta.servlet.

Also my work involve less and less OSGi, because let's be honest - while being great concept and set of specifications, in practice what's usually needed is a stable runtime that doesn't rewire itself every time you install a bundle. And that was the biggest promise of OSGi - installation of a bundle, service registration changes the runtime to reflect updated state. While it's important in embedded systems, automotive etc. OSGi didn't win the application server market... And nowadays it's really easier and faster to restart entire flat-classpath application than to recalculate (OSGi resolver) wires between modified set of bundles.

I will be monitoring OSGi related issues (please notify me by a mention if you remember ;)), but I can't promise I'll work/help immediately on it...