Saturday, January 31, 2009

Against the viral Commons-Logging

Years ago I wrote a blog post about how to make your application Commons-Logging (JCL) free by using SLF4J.

However, there is still a problem if you're writing a Maven2 based application: even if you're using SLF4J, you will probably end up with a viral JCL jar in your classpath!
That's because JCL is still used by a lot of projects, and Maven places it in your classpath as a transitive dependency.

Fortunately enough, there's still a way to completely, and easily, get rid of it thanks to the jcl-over-slf4j module, and a little Maven trick.

Here's the receipt:

  1. Add the following SLF4J dependencies:

    • slf4j-api

    • logback-classic (or your SLF4J implementation of choice).

    • jcl-over-slf4j

  2. Configure the JCL dependency with scope provided.

So here's how your Maven dependencies should look like:

By doing so, JCL will not be included in your classpath (because Maven considers it to be externally provided), while under the hood will be implemented by SLF4J thanks to the jcl-over-slf4j module.

That's all, folks.
Now you have one, and only one, safe logging library!


Johannes Brodwall said...

I think commons-logging will still be in the classpath. It just won't be included in war-files etc.

This may be sufficent, but it does leave room for some strange behaviour.

Sergio Bossa said...

Hi Johannes, thanks for your comment.
What do you mean when saying it will be in the classpath as well? It will not be included through the project dependencies (ie war libs), so what kind of classpath are you referring to?

Ceki said...

I quite like this idea. Compared to the "commons-logging 99" approach, it achieves the same without without including any new jars.

Sergio Bossa said...

Thanks for your comment, Ceki.
And thanks for your wonderful logging libraries ;)


Sergio B.

Stephen said...

I know this comment comes well after the original post, but hopefully future search visitors will find it helpful.

Regarding Johannes comment, it will show up on the classpath when using Eclipse and the maven-eclipse-plugin, for instance. This can lead to weird behavior when running tests in Eclipse.

My preferred technique is to use exclusions in a company-wide parent pom to prevent commons-logging from coming in. I combine this with using the maven-enforcer-plugin with bannedDependencies rule to ban commons-logging (and log4j, in my case, because I want to use logback). That way I'm notified if commons-logging every creeps back in, and I can just add the new exclusion. Not quite as convenient, but more correct and safer.

hugginss jetterees said...

Even though windows 7 ultimate activation key the move could aid Microsoft in mobile, additionally, it could upset the computer software maker's other Windows Telephone partners and push them away windows 7 professional retail version from the platform. Microsoft mentioned it will continue to license the operating system to other vendors for the time getting, but that could alter inside the future.