Allow spring-jcl to be found by Commons Logging's service discovery [SPR-16585]

[spring-projects-issues]

Andy Wilkinson opened SPR-16585 and commented

I've just learned about a useful behaviour of jcl-over-slf4j which allows it to work even when the Commons Logging jar has got onto the classpath somehow.

jcl-over-slf4j contains a META-INF/services/org.apache.commons.logging.LogFactory file which means that it's found by Commons Logging's standard discovery mechanism. spring-jcl has no such file. As a result, when Commons Logging is on the classpath and is being used, it falls back to its default factory and creates Jdk14Logger instances.

Would it be possible for spring-jcl to provide a META-INF/services/org.apache.commons.logging.LogFactory so that it's a better jcl-over-slf4j replacement and continues to work even when Commons Logging is on the classpath?

---

Affects: 5.0.4

Reference URL: spring-projects/spring-boot#12457

Issue Links:

• Provide an Apache Commons Logging's LogFactory provider in spring-jcl to support WebSphere's Parent-First classloader [SPR-15903] #20457 Provide an Apache Commons Logging's LogFactory provider in spring-jcl to support WebSphere's Parent-First classloader
• java.lang.AbstractMethodError: org.apache.commons.logging.LogFactory.setAttribute(..) [SPR-17302] #21835 java.lang.AbstractMethodError: org.apache.commons.logging.LogFactory.setAttribute(..)
• spring-jcl routes logging inefficiently against SLF4J with log4j-to-slf4j setup [SPR-17586] #22118 spring-jcl routes logging inefficiently against SLF4J with log4j-to-slf4j setup

Referenced from: commits 0b86c71, 31bfc1d

1 votes, 5 watchers

[spring-projects-issues]

Andy Wilkinson commented

The current behaviour of spring-jcl is continuing to cause problems for Spring Boot users. This issue is the latest example. Arguably, this is a regression from Spring Boot 1.5, but, without dropping spring-jcl, fixing it is out of our control. Could a fix for this issue please be considered in Framework 5.0.x?

[spring-projects-issues]

Juergen Hoeller commented

On reconsideration, I'm afraid this has to remain a Spring Framework 5.1 topic since it requires quite some refactoring and specific adaptation to the standard Commons Logging LogFactory implementation, whereas we currently fully replace that class and don't have to deal with the peculiarities of its default implementation at all.

I'd rather have such a major revision going through the 5.1 RC phase which isn't far away. There is a clean workaround for the time being - exclusion of standard commons-logging - which will remain the recommended solution in any case since a clean classpath is always preferable to messy Commons Logging service discovery with overlapping packages.

Of course, ideally, those remaining few cases that drag in the commons-logging artifact should simply go away. Could we get in touch with those project maintainers to get rid of their their hard dependency there, or otherwise include them in Boot's dependency management with a hard commons-logging exclusion on our side?

[spring-projects-issues]

Juergen Hoeller commented

I've refactored spring-jcl to provide a LogFactoryService class now, suitable as a subclass for the standard Commons Logging LogFactory implementation and its service discovery mechanism. In combination with a corresponding META-INF entry, this works fine for me locally when commons-logging comes first on the classpath, nevertheless delegating to our new LogDelegate underneath. In regular spring-jcl scenarios, that delegate is called directly from our LogFactory replacement, providing the same efficiency as before.