Bug 1098410 - slf4j: Undeclared bundling of log4j, apache-commons-logging
Summary: slf4j: Undeclared bundling of log4j, apache-commons-logging
Alias: None
Product: Fedora
Classification: Fedora
Component: slf4j
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Michael Simacek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1098237
TreeView+ depends on / blocked
Reported: 2014-05-16 06:42 UTC by Florian Weimer
Modified: 2014-05-16 12:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-05-16 12:22:32 UTC
Type: Bug

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.