As mentioned in the reference documentation, spring-jcl provides its own Commons Logging bridge, with classes like org.apache.commons.logging.LogFactory.
When commons-logging:commons-logging dependency is in the classpath (either included directly or transitively via dependency like com.opencsv:opencsv for example), it leads to dulicated classpath entries on the JVM and broken native compilation due to a build-time initialization error (see oracle/graal#6711 related issue).
This issue intends to introduce a warning when both spring-jcl and commons-logging are found in the classpath, to hint about excluding such commons-logging dependency.
Comment From: vpavic
After picking up Spring Framework 6.0.10, in one of the projects I'm working on we're seeing this warning logged even after excluding commons-logging from all dependency configurations. It turns out the reason is that one of the dependencies we use shades commons-logging meaning we have no way of excluding it and getting rid of warning that gets logged directly to stdout.
Comment From: jhoeller
To some degree this is the intention behind that log statement, becoming aware of such an implicit commons-logging overlap in the classpath. The log statement is rather friendly in its wording already, any suggestion for what we could do better there?
BTW in such a scenario, you could also try to remove spring-jcl instead, relying on plain Commons Logging. However, you'd need the corresponding bridges to Log4J or SLF4J on your classpath in addition.
Comment From: vpavic
I can try with removing spring-jcl indeed, thanks for the suggestion.
The log statement is rather friendly in its wording already, any suggestion for what we could do better there?
The wording itself is fine, but if someone decides (or has to) live with this, the fact that warning is written directly to stdout is a bit inconvenient, especially if your infra expects log entries of a certain structure (for example, JSON).
Additionally, after picking up the upgrade I originally had this logged multiple times - due to having commons-logging pulled-in both transitively and as the aforementioned shaded copy.
It's a bit unfortunate that this requires so much fiddling (if the solution really is to exclude spring-jcl) having in mind the component that logs this warning was (to my understanding from reading https://github.com/spring-projects/spring-framework/issues/21127) introduced exactly to allow spring-jcl and commons-logging to coexist.