Bug 1098410

Summary: slf4j: Undeclared bundling of log4j, apache-commons-logging
Product: [Fedora] Fedora Reporter: Florian Weimer <fweimer>
Component: slf4jAssignee: Michael Simacek <msimacek>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: mizdebsk, msimacek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-16 12:22:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1098237    

Description Florian Weimer 2014-05-16 06:42:00 UTC
slf4j bundles and compiles Java class sources from other logging libraries.

For log4j-over-slf4j-0:1.7.7-1.fc21.noarch, the file /usr/share/java/slf4j/log4j-over-slf4j.jar includes the class org/apache/log4j/spi/HierarchyEventListener, which is also available from log4j-0:1.2.17-16.fc21.noarch.

For jcl-over-slf4j-0:1.7.7-1.fc21.noarch, /usr/share/java/slf4j/jcl-over-slf4j.jar includes the class org/apache/commons/logging/Log, which is also available from apache-commons-logging-1.1.3-11.fc21.noarch.

I have not checked whether the class files are copied from the compiled versions in the build tree, or from the build dependencies.  Either approach is problematic as far as the Fedora guidelines against bundled libraries are concerned.

Comment 1 Michael Simacek 2014-05-16 08:31:12 UTC
The mentioned classes are part of the source and most of them are not copies of anything, they are another implementations that share the same name and package in order to provide replacement for corresponding functionality in log4j/commons-logging. There are some classes and interfaces that look like a copy, but I'm not sure whether they could be unbundled because having original log4j/commons-logging would then create name clashes with the reimplemented ones. And if a package provides a replacement implementation of something, it probably shouldn't pull in the thing it is trying to replace.

Comment 2 Florian Weimer 2014-05-16 11:58:01 UTC
Thanks for explaining what is going on.  It is surprising that five classes end up being binary identical.

How is this supposed to work when two different libraries put slf4j and another logging framework on the classpath?

Is such redefinition of classes from other libraries a common occurrence in Fedora Java packages?  With the advent of default methods in Java 8, such a reliance on unchanging interfaces seems rather problematic.

Comment 3 Mikolaj Izdebski 2014-05-16 12:08:17 UTC
FWIW, each logging framework claims to be the best one and provdes adapters implementing other APIs for easier migration.  These adapters are not supposed to be used together with libs they are replacing.