Bug 1098410

Summary:	slf4j: Undeclared bundling of log4j, apache-commons-logging
Product:	[Fedora] Fedora	Reporter:	Florian Weimer <fweimer>
Component:	slf4j	Assignee:	Michael Simacek <msimacek>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	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:
Embargoed:
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.