Log4j2 has only log4j-slf4j18-impl artifact which was using long-in-development SLF4J 1.8.0-beta versions. There's no binding (actually service provider now) for SLF4J 2.0 in Log4j2.
The most important change in SLF4J2 is the removal of static binding, which historically was a brilliant idea by the way after the hellish configuration of commons-logging discovery mechanisms... See https://www.mail-archive.com/dev@slf4j.org/msg02034.html:
SLF4J does not rely on any special class loader machinery. In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time of each binding. Each binding is hardwired to use one and only one specific logging API implementation. Each binding corresponds to one jar file. In your code, in addition to slf4j-api.jar, you simply drop the binding of your choice, that is a jar file, onto the appropriate class path location. As a consequence of this simple approach, SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).
SLF4J 2 now relies on Java Service Loader (META-INF/services/org.slf4j.spi.SLF4JServiceProvider).
grgrzybek
commented
1 year ago
Log4j2 has only
log4j-slf4j18-implartifact which was using long-in-development SLF4J 1.8.0-beta versions. There's no binding (actually service provider now) for SLF4J 2.0 in Log4j2.The most important change in SLF4J2 is the removal of static binding, which historically was a brilliant idea by the way after the hellish configuration of commons-logging discovery mechanisms... See https://www.mail-archive.com/dev@slf4j.org/msg02034.html:
SLF4J 2 now relies on Java Service Loader (
META-INF/services/org.slf4j.spi.SLF4JServiceProvider).