[FIXED JENKINS-12334 JENKINS-12446 JENKINS-12650]

Bundle slf4j binding to the war. See the comment in war/pom.xml for detailed discussion. This is fundamentally a "damned if I do, damned if I don't" situation, but given that JENKINS-12334 is a fatal error, and the downside of bundling the binding jar is "multiple binding" warning, it seems like the lesser evil is to bundle it and risk some warnings. Cherry-picked-from: ef1ad6c
jenkinsci · Mar 19, 2012 · 7cc71cd · 7cc71cd
1 parent 38bd4aa
commit 7cc71cd
Show file tree

Hide file tree

Showing 3 changed files with 47 additions and 28 deletions.
diff --git a/maven-plugin/pom.xml b/maven-plugin/pom.xml
@@ -47,39 +47,13 @@ THE SOFTWARE.
     <aetherVersion>1.13</aetherVersion>
     <sisuInjectVersion>2.3.0</sisuInjectVersion>
     <wagonVersion>2.2</wagonVersion>
-    <slf4jVersion>1.6.2</slf4jVersion> <!-- < 1.6.x version didn't specify the license (MIT) -->
   </properties>
 
   <issueManagement>
     <system>jira</system>
     <url>https://issues.jenkins-ci.org/browse/JENKINS/component/15487</url>
   </issueManagement>
 
-  <dependencyManagement>
-    <dependencies>
-      <!-- SLF4J is used by wagon-webdav-jackrabbit dep --> 
-      <dependency>
-        <groupId>org.slf4j</groupId>
-        <artifactId>slf4j-api</artifactId>
-        <version>${slf4jVersion}</version>
-      </dependency>
-      <dependency>
-        <groupId>org.slf4j</groupId>
-        <artifactId>slf4j-nop</artifactId>
-        <version>${slf4jVersion}</version>
-      </dependency>
-      <dependency>
-        <groupId>org.slf4j</groupId>
-        <artifactId>slf4j-jdk14</artifactId>
-        <version>${slf4jVersion}</version>
-      </dependency>
-      <dependency>
-        <groupId>org.slf4j</groupId>
-        <artifactId>jcl-over-slf4j</artifactId>
-        <version>${slf4jVersion}</version>
-      </dependency>
-    </dependencies>
-  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.jenkins-ci.main</groupId>
@@ -354,7 +328,7 @@ THE SOFTWARE.
       <artifactId>wagon-webdav-jackrabbit</artifactId>
       <version>${wagonVersion}</version>
       <exclusions>
-        <exclusion><!-- bundling binding creates a problem with app servers that use different versions of slf4j -->
+        <exclusion><!-- jcl-over-slf4j version needs to match with slf4j-api version, which makes this fragile. let's not try to intercept jcl calls -->
           <groupId>org.slf4j</groupId>
           <artifactId>jcl-over-slf4j</artifactId>
         </exclusion>

diff --git a/pom.xml b/pom.xml
@@ -89,6 +89,7 @@ THE SOFTWARE.
     <project.patchManagement.url>https://api.github.com</project.patchManagement.url>
     <patch.tracker.serverId>jenkins-jira</patch.tracker.serverId>
 
+    <slf4jVersion>1.6.2</slf4jVersion> <!-- < 1.6.x version didn't specify the license (MIT) -->
   </properties>
 
 
@@ -205,6 +206,27 @@ THE SOFTWARE.
         <version>3.1.0</version>
       </dependency>
 
+      <!-- SLF4J used in maven-plugin and core -->
+      <dependency>
+        <groupId>org.slf4j</groupId>
+        <artifactId>slf4j-api</artifactId>
+        <version>${slf4jVersion}</version>
+      </dependency>
+      <dependency>
+        <groupId>org.slf4j</groupId>
+        <artifactId>slf4j-nop</artifactId>
+        <version>${slf4jVersion}</version>
+      </dependency>
+      <dependency>
+        <groupId>org.slf4j</groupId>
+        <artifactId>slf4j-jdk14</artifactId>
+        <version>${slf4jVersion}</version>
+      </dependency>
+      <dependency>
+        <groupId>org.slf4j</groupId>
+        <artifactId>jcl-over-slf4j</artifactId>
+        <version>${slf4jVersion}</version>
+      </dependency>
     </dependencies>
   </dependencyManagement>
   <dependencies>

diff --git a/war/pom.xml b/war/pom.xml
@@ -117,9 +117,32 @@ THE SOFTWARE.
       <artifactId>sshd</artifactId>
       <version>1.2</version>
     </dependency>
+    <dependency>
+      <!--
+        We bundle slf4j binding since we got some components (sshd for example)
+        that uses slf4j.
+
+        The problem with not shipping any binding in the war is that if the
+        servlet container does use slf4j in itself, then we got a classloader
+        constraint violation (see JENKINS-12334) as we try to load StaticLoggerBinder
+        which resides in the binding jar (this jar would be from container implementation,
+        which relies on slf4j api in the container, when we have our own slf4j API jar
+        statically depending on the binding jar.)
+
+        We also get tickets like JENKINS-12650 for not reporting logs at all
+        (although this is a non-fatal problem.)
+
+        The downside of adding a jar is that we can potentially get "multiple binding jar"
+        warning like http://www.slf4j.org/codes.html, but that's at least non-fatal.
+      -->
+      <groupId>org.slf4j</groupId>
+      <artifactId>slf4j-jdk14</artifactId>
+    </dependency>
+
 
     <!-- offline profiler API when we need it -->
-    <!--dependency>
+
+    <!--dependency
       <groupId>com.yourkit.api</groupId>
       <artifactId>yjp</artifactId>
       <version>dontcare</version>