Skip to content
Permalink
Browse files

[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.
  • Loading branch information...
kohsuke committed Feb 10, 2012
1 parent 83ad02d commit ef1ad6ca29c313fa0b4bc6f5dcd8344046221049
Showing with 52 additions and 28 deletions.
  1. +5 −0 changelog.html
  2. +1 −27 maven-plugin/pom.xml
  3. +22 −0 pom.xml
  4. +24 −1 war/pom.xml
@@ -65,6 +65,11 @@
Fix launching browser too early to http://localhost:8080 in OS X
installer.
(<a href="https://issues.jenkins-ci.org/browse/JENKINS-12622">issue 12622</a>)
<li class="bug">
Bundled slf4j binding to avoid classloader contraint violation in JBoss
(<a href="https://issues.jenkins-ci.org/browse/JENKINS-12334">issue 12334</a>,
<a href="https://issues.jenkins-ci.org/browse/JENKINS-12446">issue 12446</a>,
<a href="https://issues.jenkins-ci.org/browse/JENKINS-12650">issue 12650</a>)
<li class="bug">
Fixed a UI problem with the "save" button that sticks to the bottom.
<li class="rfe">
@@ -47,39 +47,13 @@ THE SOFTWARE.
<aetherVersion>1.13.1</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>
22 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>
@@ -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>

0 comments on commit ef1ad6c

Please sign in to comment.
You can’t perform that action at this time.