Javalobby

Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 141 posts at DZone. You can read more from them at their website. View Full User Profile

Logback Config Files Not Being Found

06.12.2011
| 2890 views |
  • submit to reddit

We Recommend These Resources

Anyone who has a project set with a bunch of jar projects and an outer war one has probably had occasion to be working along and then suddenly, trying to raise the log level doesn‘t work. The main way this occurs is that logback is an implementation of the slf4j standard. But there are other implementations, and if they end up in your project, you will get an error about multiple bindings.

The simplest way to resolve this (with the m2eclipse plugin) is to go into the dependencies view and type in slf4j and make sure all you are seeing is the following:

If you see slf4j coming in from any other jars, just highlight, right click and choose Exclude Maven Artifact, comme ça:

BTW, there‘s a new version today: 0.9.29. Went looking for some release notes or something. That project website looks like it was commissioned by a state agency. And I guess I knew this, but they have an eclipse plugin that supports filtering! But they don‘t have an update site.. ??

 

From http://www.jroller.com/robwilliams/entry/logback_config_files_not_being

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

John J. Franey replied on Mon, 2011/06/13 - 9:10am

First, unless there is compile time dependency on logback specific API, sfl4j-api should be a primary (not transitive) dependency at 'compile' scope. Logback (or any developer or deployer preferred framework) should be in 'test', 'provided' or 'runtime' scope. Having a compile time dependency on any logging framework (logback, log4j, jul) compromises the ability to switch from one logging environment to another at deploy or runtime, so your sample above ought not be taken as an example for general case. Also, if your container has an logging framework (and most do), it might have an slf4j implementation already. Then in your project, slf4j-api should not be a 'compile' scope. It should be 'provided'. And logback would definitely NOT be runtime or compile scope.

Second, slf4j-api is a facade and does not have any logging configuration state. I would not expect eliminating the sfl4j-api would resolve the issue of having multiple, conflicting configuration files. How do you explain it?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers