Hello. The new generation of logback is modularized in the JPMS sense, and uses services (ServiceLoader) to find logging implementations.
This means if you try to use a reasonably new version of logback with
Felix Logback, you'll see this sort of thing:
[ERROR] Resolution failed. Capabilities satisfying the following requirements
could not be found:
[<<INITIAL>>]
⮡ osgi.identity: (osgi.identity=org.apache.felix.logback)
⮡ [org.apache.felix.logback version=1.0.0]
⮡ osgi.wiring.package:
(&(osgi.wiring.package=ch.qos.logback.classic.spi)(&(version>=1.2.0)(!(version>=2.0.0))))
⮡ [ch.qos.logback.classic version=1.3.0.alpha4]
⮡ osgi.extender:
(osgi.extender=osgi.serviceloader.registrar)
It seems that it's now required to use something like Aries SPI Fly
(the reference implementation of the OSGi ServiceLoader Mediator spec)
just to use Logback.
Personally, I stay away from bytecode weaving in all forms, because I
really don't want to deal with problems caused by a third party tool
rewriting the code of other third party libraries, the code of which
I've never even seen!
Is there some way out of this mess?
I previously did something like this:
https://www.io7m.com/documents/brutal-felix-logging/
... but that's only any use if you're embedding a container, and so is
more or less incompatible with using something like the bnd exporter.
--
Mark Raynsford | http://www.io7m.com
pgpzBvc4fFKG6.pgp
Description: OpenPGP digital signature
