Prepare for Log4j2 3.0

[grgrzybek]

https://www.mail-archive.com/announce@apache.org/msg08284.html

[wborn]

Do the preparations also include fixing the "The use of package scanning to locate plugins is deprecated and will be removed in a future release" warnings introduced by LOG4J2-3644 in the PluginManager?

They seem to be caused by the code in the PaxLoggingServiceImpl.

[grgrzybek]

I didn't look at it yet... But scanning and OSGi in the same sentence always give me a headache...

[wborn]

I only saw these warnings while debugging in Eclipse and not in Karaf. Apparently org.ops4j.pax.logging.DefaultServiceLog.level was configured to WARN instead of ERROR which is the Karaf default. I'll raise the log level in Eclipse as well as workaround to suppress these warnings flooding stdout. 🙂

The PluginManager got completely removed in Log4j 3 in favor of using the ServiceLoader mechanism which may also give headaches. 😉

See: https://logging.apache.org/log4j/3.x/

All plugins constructed using Log4j 3.x are now located using Java’s ServiceLoader. This avoids many of the problems users had packaging plugins in "shaded" jars as that technology directly supports ServiceLoader. Plugins constructed using Log4j 2.x will still function in Log4j 3.x.

[splatch]

I didn't look at it yet... But scanning and OSGi in the same sentence always give me a headache...

According to log4j 3 release message, it works with regular java service locator. And if it works with service locator, we can build a basic bundle tracker to make it work without Aries spi-fly. WDYT?

[mattrpav]

+1 BundleTracker ftw

[grgrzybek]

Generally +1.

The problem I see is that Log4j3's ServiceLocator locates everything when started/loaded.

In OSGi, if bundle tracker tracks new bundles with plugins in their /META-INF/services we'd probably need to restart entire LogManager. That's of course the same as with SPI-Fly + ServiceLocator...

So in the end +1 to not use SPI-Fly. However I'm too busy this week to think about reloading consequences ;)