Hello all, Reading Andreas Veithen's message I would like to make the following comments:
> - SLF4J needs at least two artifacts to work: the API and (a binding > to) a concrete implementation. As pointed out in red in the SLF4J FAQ, > artifacts from different versions of SLF4J are incompatible with each > other. However, in a Maven project you easily end up with a situation > where there is a mismatch between the API version and the > implementation version. For somebody familiar with Maven and SLF4J > (and class loading if the problem occurs in an EAR project e.g.) this > is easy to fix, but many developers don't have all this knowledge. The FAQ says that you should be careful not to mix different versions of slf4j-api and slf4j-binding. As far as client code is concerned, SLF4J api has been backwards compatible since SLF4J 1.0, that is for about 5 years. Moreover, SLF4J 1.5.5 above are all compatible *even* if you mix different versions of slf4j-api and slf4j binding. For older versions, slf4j will emit a warning telling you to use compatible versions for sfl4j-api and for slf4j-binding. Ironically, the incompatibility issues when mixing different versions of slf4j-api and slf4j-bindings in versions prior to 1.5.5, stem from this warning itself. Talk about shooting oneself in the foot. Sigh. > - In general, frameworks using SLF4J cause a dependency hell: some > frameworks only depend on the SLF4J API (which in my opinion is the > correct approach), but then you need to add additional SLF4J > dependencies to your project; other frameworks also introduce > dependencies on a particular binding/implementation, but then you need > to exclude these dependencies if the choice doesn't match the choice > you have made in your project. Libraries should not impose a logging implementations on their clients. Doing so is contrary to the spirit and raison d'etre of SLF4J. If one of an application's dependencies declares an slf4j binding and transitively imposing it downstream then this can be dealt with by excluding that slf4j binding in the applications pom.xml. While a possibility, I am not aware of any open-source library which declares an slf4j binding (and thus transitively imposing it downstream). Whatever the declared SLF4J versions in the dependencies of a project, declaring the same version for slf4j-api and slf4j-bnding in the applications pom.xml is sufficient to deal with any version mismatches. Given the above, your statement about SLF4J causing dependency hell sounds exaggerated to me. > To summarize: commons-logging in general works out of box and you only > need to care about it when setting up a particular logging policy; > SLF4J causes much more troubles even before you start thinking about > logging. That is certainly not the feedback we are getting from SLF4J users. On the contrary, most SLF4J users are enchanted with the simplicity and stability SLF4J offers. > That being said, I like the approach used by SLF4J of statically > binding a concrete logging implementation to an abstract API and > prefer that over commons-logging's approach of dynamic discovery... The dependency-hell you describe is a direct consequence of SLF4J's static binding policy. As such, it's odd you should like an approach but dislike the direct consequences. If you would like to describe the concrete issues you are having or have had in the past with SLF4J, you are most welcome to do so on the slf4j-user mailing list. I am sure you will be met with an attentive ear. In any case, my apologies for barging in uninvited into this discussion. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
