Consider migrating from Commons-Logging to SLF4j [SPR-5327]

[spring-projects-issues]

Grzegorz Borkowski opened SPR-5327 and commented

Currently Spring Framework depends on Commons-Logging. All of us know that for long time Commons-Logging has very bad reputation and is the source of many problems, bug, memory leaks etc.
The SLF4j is the newer implementation of similar idea, and many people claim it works much better than Commons-Logging. It contain even some adapter for Commons-Logging users, allowing for gradual transition. Perhaps with Spring 3, along with migration to Java 5, is the best time to migrate also to SLF4J and remove dependency on Commons-Logging?
In fact, you can probably do it somehow automatically, writing the script that will replace in all java files the imports and logger types.

---

Affects: 3.0 M4

Attachments:

• SPR-5327.patch (511.88 kB)

Issue Links:

• Revisit subsystem-oriented logging [SPR-8122] #12774 Revisit subsystem-oriented logging
• 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 f4763a8, 1a06b6a, ad3fa50, 604a9f0, b7e37dd, 1202f67, 0400ccc

20 votes, 13 watchers

[spring-projects-issues]

Tim Wlcek commented

As I have been spending the last two days trying to migrate my project to slf4j and to fix the transitive dependencies from maven, I would dearly love to see this issue resolved. At least consider marking clogging as optional in the spring poms.

[spring-projects-issues]

Carlos Zuniga commented

Here is a stab at changing the logging framework from Commons Logging to SLF4J. Feedback is welcome.
Since this issue has not been assigned I don't know if the commiters will be able to see it. May be the watchers can ping them if you have more direct communication with them.

Carlos

[spring-projects-issues]

adrian commented

JCL can be a pain to setup on Websphere, see https://www.ibm.com/developerworks/forums/thread.jspa?threadID=227753. Migrating to SLF4J would resolve this issue.

Also SLF4J provides a migration utility which could be used all the spring code baseline (didn't tested it though) : http://www.slf4j.org/migrator.html

[spring-projects-issues]

Neale Upstone commented

This doesn't need to be nailed down as JCL or SLF4J.

The main problem here, for which I'm going to report a separate bug, is that the logging dependency is not left for the runtime to provide, but is instead pulled in as "compile" scope within the Spring 3.0M3 POMs.

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>com.springsource.org.apache.commons.logging</artifactId>
  <version>1.1.1</version>
  <scope>compile</scope>
</dependency>

Could read:

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>com.springsource.org.apache.commons.logging</artifactId>
  <version>1.1.1</version>
  <scope>provided</scope>
</dependency>

I agree that SLF4J is now a far better choice than JCL. It can work very nicely with Maven.

[spring-projects-issues]

Dave Syer commented

The current proposal (for discussion) from the Spring team is that we simply switch to declaring jcl-slf4j as the primary dependency, requiring users to provide their own bindings from there. This makes it easy to integrate third-party libraries that already use slf4j without going to whole hog ourselves. Or we could leave things as they are, and allow people to adapt in that case by using the same bindings (log4j, JUL, etc.) to our commons-logging and the third-party slf4j.

The suggestion from Neale that we simply make commons-logging a "provided" dependency is interesting, signalling that it is mandatory but must be provided by the host (who can choose jcl-slf4j if they wish). I would prefer to leave the primary logging dependency as "compile" scope, but it comes to the same thing really - when you run an application for the first time it will fail and tell you that there is a missing class. The one saving grace of commons-logging is that it doesn't do that, but of course that is also its downfall: the discovery process is flawed.

Using "provided" scope doesn't make life any easier for WAS users. Only moving our primary dependency to sl4j would help, and even then it might not help everyone - presumably there are people who actually like having WAS control their logging configuration, and all they have to do is leave out commons-logging from their WAR/EAR packaging.

[spring-projects-issues]

Grzegorz Borkowski commented

IMHO, the primary logging dependency of Spring should be switched to SLF4J. From all possible decisions about logging library choice, in year 2009 this one seems the most reasonable.
The only question is: make it compile scope or provided scope. I'd rather opt for compile scope, because most application servers probably don't contain SLF4J ootb. But I'm not 100% sure about this choice.

[spring-projects-issues]

Stevo Slavić commented

See here how Jetty (maven plugin) did it.

[spring-projects-issues]

Dave Syer commented

Stevo: I looked at what Jetty does, and we don't want to go there because it involves adding yet another logging abstraction with runtime classpath discovery (like commons-logging but smarter).

Grzegorz: SLF4J is undoubtedly superior to commons-logging, but the basic JCL API that we use in Spring by and large is not so evil. And we have a strong commitment to backwards compatibility: i.e. most if not all applications should work just by upgrading the version of Spring. Admittedly there has never been a concerted effort to match that commitment with our declared dependency management artifacts (POMs etc.), but that's no reason not to consider the general principle.

I actually think now that the best thing we can do is leave commons-logging as a primary compile-scoped dependency, but only in spring-core. Features of that approach are:

• All existing applications continue to work with no changes.
• All new applications work out of the box with no additional dependencies to declare other than Spring.
• To switch to SLF4J, just exclude commons-logging from one dependency (spring-core) and add the jcl-slf4j bridge, plus your favourite binding.
• If using Hibernate (or other SLF4J external library) as well as Spring, you have a choice:

1. switch Spring to SLF4J with the bridge as above
2. add SLF4J bindings to get match your choice for the external library (e.g. slf4j-log4j12)
3. add a different SLF4J binding and have separate log configuration for Spring and the external library

\
To make that happen we need to make sure that commons-logging is compile scoped, and that it is the only mandatory (not optional and not test scoped) logging dependency, and that it is only declared in core-spring. I'm not sure if the last point is strictly possible yet until I try it (i.e. there might be Spring libraries that depend on commons-logging but not core-spring).

[spring-projects-issues]

allnightlong commented

In my opinion, major release is the best moment to switch to modern slf4j. If spring wouldn't do this, all community have to wait until the next major release (about 3 years?), for another chance.
Also, there are a lot of developers, which considering spring as flagship of java frameworks. And if spring finally make right descision, it will give a great leap to whole industry.
Also I think, that shipping spring with sl4j-api and jcl-over-slf4j will resolve all backward compability problem.

[spring-projects-issues]

Grzegorz Borkowski commented

Keeping backward compatibility is an important point, and this must be seriously considered.
There are several other considerations, though:

1. putting explicit dependency on JCL only in spring-core (and use is as transitive dependency in other spring modules) could work, but it's not semantically correct, I think - because other spring modules use JCL directly in their code too. So in theory, they should declare JCL as their direct dependency - at least that's how I understand dependency management.
2. SLF4J has one significant advantage over other logging APIs: parametrized logging (i still can't understand why it's not built into JUL since Java 5 - varargs seems perfect match for this). I've just look at first Spring class code that I've found: CachedIntrospectionResults:

if (logger.isDebugEnabled()) {
  logger.debug("Not strongly caching class [" + beanClass.getName() + "] because it is not cache-safe");
}

The same code using SLF4J would look like:

logger.debug("Not strongly caching class [{}] because it is not cache-safe", beanClass.getName());

I've seen some projects where "if isDebugEnabled" was the most repeatable pattern around the code, that's why I'm allergic to it :) This means that new Spring code will be able to use this approach, which is better for code readability.
3) JCL is not a public API of Spring; that's only the dependency, so changing it shouldn't break someone else's code. If someone wants to switch from Spring <3.0 to 3.0 in your project, they probably want to rebuild the project anyway. Most projects nowadays use Maven or Ivy anyway, so the dependency would automatically be updated. Besides, it's not a big deal to publish information about the change of logging dependency and tell people how to manage it.

[spring-projects-issues]

Juergen Hoeller commented

Actually, we do expose a JCL Log in plenty of Spring-provided base classes... Changing the type of that field to an SFL4J logger would break binary compatibility with external subclasses using that logger, not only with user code but also with third-party libraries that are built on Spring (and can't be recompiled as easily as user code).

Juergen

[spring-projects-issues]

adrian commented

Changing the type of that field to an SFL4J logger would break binary compatibility

Ok, this is a problem, but perhaps with version 3, you can allow yourself to break compatibility (and use private modifier for SLF4J logger attributes) ?
Or deprecating logger attribute and switch to SLF4J in Spring 3.1 (bof...) ?
A lot of open source projects [1] are switching to SLF4J, so perhaps it would be a good idea also for Spring to switch to SLF4J (hence we have only one logging facade in our libraries).

[1] Some projects of those projects :

• weld : http://repo2.maven.org/maven2/org/jboss/weld/weld-core/1.0.0/weld-core-1.0.0.pom
• hibernate : http://opensource.atlassian.com/projects/hibernate/browse/HHH-2696
• hibernate validator : http://repository.jboss.com/maven2/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.pom

Other projects not using SLF4J

• struts 2 uses its own wrapper (around JDK Logging or commons logging) : http://repo2.maven.org/maven2/com/opensymphony/xwork-core/2.1.6/xwork-core-2.1.6-sources.jar (class LoggerFactory).

Perhaps contacting main open source projects for a 'global' switch to SLF4J would be a good idea (struts2, wicket, gwt, ...) ?

About using jcl-slf4j and modifying spring's pom.xml dependencies to jcl-slf4j.

I thought this issue was more about modifying spring source dependency towards jcl. Everyone can already use Spring 2.5.6 with jcl-slf4j (I'm already using this setup in my projects).

Switching to SLF4J for WAS users

It would enable some of us to setup spring application with parent_first classloader setting (I'm tied to parent_last since I'm using jcl-slf4j)... until WAS also switches to from JCL to SLF4J)

[spring-projects-issues]

Grzegorz Borkowski commented

Actually, we do expose a JCL Log in plenty of Spring-provided base classes...

Well, if that's the case, than situation is much more difficult. I've never used such Spring logger, but many others could have done it. Spring always focused on keeping backward compatibility, so I understand that changing all loggers to SLF4J is problematic.

One choice is to break this compatibility, as it was suggested by others - major releases theoretically allow for this; besides, the change is not that big, and other libraries can be quite easily aligned. Spring already did some breaking compatibility change in 3.0, by changing naming scheme of modules (for maven/ivy), which cases problems in some cases.

However, if you decide that you simply can't do it, than we have to use some of the approaches proposed above, like e.g. restrictive dependency on JCL to spring-core, ... others?

[spring-projects-issues]

Dave Syer commented

Resolving this one as Won't Fix, but this is a good discussion. I have captured some of it in a new section of the user guide.

[spring-projects-issues]

Jon Fisher commented

So to summarize, the only reason for not migrating is backwards compatibility, is this correct? :(