Description
Ibrahim Ghazal opened SPR-15903 and commented
In #19081 (specifically this comment), Juergen Hoeller said:
In "Parent First" mode, it's always WebSphere's own version of Commons Logging getting picked up. It does not make a difference whether the application contains a variant of Commons Logging itself: an application-level variant is always being ignored. Therefore it doesn't make a difference whether we embed our own variant versus JCL-over-X bridges or the standard Commons Logging jar.
In practice, there is a difference. When a real Commons Logging JAR is picked up (such as when using WebSphere's Parent-First classloader), spring-jcl
is not used and spring's logs end up going to Commons Logging's default implementation (most likely JUL). But when log4j-jcl
or jcl-over-slf4j
are used instead of spring-jcl
, logs are redirected to Log4j2 or SLF4J respectively.
This is because Commons Logging searches for a provider using the JAR Services Discovery mechanism (META-INF/services/org.apache.commons.logging.LogFactory
file). Both log4j-jcl
and jcl-over-slf4j
provide this and so they just work even in such situations.
I think it's quite easy to provide this in spring-jcl
too.
(The linked comment above mentions implementing the discovery mechanism in spring-jcl
, but this issue is asking for the opposite (providing a provider)).
Affects: 5.0 RC3
Issue Links:
- 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
Referenced from: commits 0b86c71