Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove duplicate commons logging classes from spring-jcl [SPR-16062] #20611

Closed
spring-issuemaster opened this issue Oct 12, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Oct 12, 2017

Sven Haster opened SPR-16062 and commented

spring-jcl has duplicated a number of classes from apache commons logging, such as org.apache.commons.logging.Log
spring-core has a dependency on spring-jcl and therefore everyone who has a dependency on spring-core gets these duplicate classes and has errors resulting from this if they also depend on commons logging or slf4j-jcl

This is less than ideal and goes against convention. It would be better to either a) have a dependency on commons-logging or b) if you really want to include these classes, change the package names to something like org.springframework.x.y


Affects: 5.0 GA

Issue Links:

  • #20509 spring-jcl does not include exported packages of java commons logging
  • #19081 Revisit Commons Logging vs java.util.logging vs SLF4J vs Log4j 2
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 12, 2017

Juergen Hoeller commented

This is by design: spring-jcl is a standard Commons Logging bridge just like jcl-over-slf4j is, with first-class support for Log4J 2 as well as SLF4J (instead of having to mess with manual excludes and extra bridges for either of those two). If you prefer a different bridge, you simply need to exclude spring-jcl from spring-core's dependencies... just like for a switch between regular commons-logging and jcl-over-slf4j against Spring Framework 4.

In other words, it's simply a new default logging bridge in Spring, primarily for backwards compatibility with existing Commons Logging API usage in the Spring ecosystem. For that reason, it's intentionally not repackaged into org.springframework. We took jcl-over-slf4j as an inspiration there; for all practical purposes, our spring-jcl is no more "against convention" than that standard SLF4J bridge or a default dependency on that bridge.

Point taken, you might have to adapt existing project dependency declarations in order to arrive at a clean classpath when upgrading to Spring Framework 5. If you're currently manually excluding commons-logging from spring-core's dependencies in order to bring in jcl-over-slf4j, simply exclude spring-jcl instead of commons-logging now... and your project classpath should be as clean as before, hanging on to your logging bridge of choice.

For a newly started project, no extra setup is necessary in the first place: Let spring-jcl do its job, picking up Log4J 2 or SLF4J or JUL by default, with no need for excludes or bridges. If you'd like to consistently use spring-jcl that way, you should simply exclude commons-logging and/or jcl-over-slf4j dependencies in other libraries that might bring those into your classpath by default. No fundamental difference, just another variant of such a bridge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.