Websphere Multiple slf4j logback bindings work around

Question

I am running an application on Websphere v8.5.5.0 and am attempting to use logback as my logging framework.

When i try to start the application, I am greeted with an error similar to this one:

[10/03/14 13:19:00:900 EST] 00000097 SystemErr     R   SLF4J: Class path contains multiple SLF4J bindings.
[10/03/14 13:19:00:900 EST] 00000097 SystemErr     R   SLF4J: Found binding in [bundleresource://266.fwk1755217229:1/org/slf4j/impl/StaticLoggerBinder.class]
[10/03/14 13:19:00:900 EST] 00000097 SystemErr     R   SLF4J: Found binding in    [wsjar:file:/C:/Program%20Files%20(x86)/IBM/WebSphere/AppServer_1/profiles/AppSrv01/installedApps/AUSSYDCVTLJ007Node02Cell/myapp.ear/lib/logback-classic-1.1.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[10/03/14 13:19:00:900 EST] 00000097 SystemErr     R   SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
[10/03/14 13:19:01:313 EST] 00000097 SystemErr     R   SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]

As the answer explains, The ibm libraries contain an implementation of the logback-classic library on the classpath already. I want to stay up to date with the latest logback so was wondering whether someone could show me how to manually choose the binding to use (without using a parent-last classloader!).

Answer 1

Actually the error messages you see in your case is a known bug of IBM WebSphere Application Server v8.5.5.0. The issue is that WAS is using is SLF4j internally but this implementation is supposed to be unknown (and unusable) from applications. Unfortunately, these error messages you see have not been blocked by the WAS framework but you can ignore them (except if you have not well used SLF4j). The good news is that this issue has been fixed in FixPack 3 (WAS 8.5.5.3). The bug is referenced by IBM Support here. So, update your WAS installation. If, after applying the fix, the error messages still occur, then, you probably have to review your SLF4J configuration and usage.

John

Answer 2

According to the SLF4J documentation, applications should pick which binding they want to use and add it to their classpath:

Declaring project dependencies for logging

Given Maven's transitive dependency rules, for "regular" projects (not libraries or frameworks) declaring logging dependencies can be accomplished with a single dependency declaration.

However, it is strongly recommended that libraries or frameworks do not declare a dependency on a specific binding:

Libraries

BASIC RULE Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

---

The problem here has more to do with Logging Separation than with dependency management. The subject of Logging Separation is discussed at length in the logback manual. The suggested "easiest approach" from the logback manual is to actually include both the SLF4J api and logback in your web application and use parent-last class loading:

Assuming your container supports child-first class loading, separation of logging can be accomplished by embedding a copy of slf4j and logback jar files in each of your applications. For web-applications, placing slf4j and logback jar files under the WEB-INF/lib directory of the web-application is sufficient to endow each web-application with a separate logging environment.

Basically, Websphere has decided to use SLF4J and logback for container-level logging. This is fine but that decision should not be exposed to applications unless the applications want to participate in the container-managed logging framework.

Until Websphere adds the ability to choose whether or not an application should participate in container-managed logging, the only workable solution is to use parent-last class loading and include SLF4J and your chosen binding in the WEB-INF/lib or equivalent directory.