spring-jcl routes logging inefficiently against SLF4J with log4j-to-slf4j setup [SPR-17586]

[spring-projects-issues]

Andy Wilkinson opened SPR-17586 and commented

If org.apache.logging.log4j.spi.ExtendedLogger (part of log4j-api) is on the classpath, spring-jcl will produce a org.apache.commons.logging.Log that logs by delegating to the Log4j2 API. In a setup where Log4j 2's implementation is not on the classpath and its log4j-to-slf4j module is being used to route logging performed via the Log4j 2 API into SLF4J, this isn't as efficient as it could be. It leaves logging being routed as follows:

Commons Logging -> Log4j2 -> SLF4J -> Logging back end

If a check was made for a type from log4j-core before choosing to route into Log4j2, this could be more efficient in log4j-core's absence:

Commons Logging -> SLF4J -> Logging back end

---

Affects: 5.0.11, 5.1.3

Issue Links:

• java.lang.AbstractMethodError: org.apache.commons.logging.LogFactory.setAttribute(..) [SPR-17302] #21835 java.lang.AbstractMethodError: org.apache.commons.logging.LogFactory.setAttribute(..)
• Allow spring-jcl to be found by Commons Logging's service discovery [SPR-16585] #21127 Allow spring-jcl to be found by Commons Logging's service discovery
• Revisit Commons Logging vs java.util.logging vs SLF4J vs Log4j 2 [SPR-14512] #19081 Revisit Commons Logging vs java.util.logging vs SLF4J vs Log4j 2

Referenced from: commits 4b45030

[spring-projects-issues]

Juergen Hoeller commented

If Log4j is present as well as org.apache.logging.slf4j.SLF4JProvider (and the SLF4J SPI), we're explicitly choosing the SLF4J facade now. This should cover the outlined case, hopefully.

As a side note, in case of the SLF4J SPI not being visible to us, we still prefer Log4j over the plain SLF4J API since the latter does not have location awareness support.