Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354269

Summary:	org.eclipse.equinox.http.jetty overrides org.slf4j.LoggerFactory causing NoSuchMethodError
Product:	[Eclipse Project] Equinox	Reporter:	Bastian Knerr <bastian.knerr>
Component:	Components	Assignee:	equinox.components-inbox <equinox.components-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	digulla, simon_kaegi
Version:	3.6.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Bastian Knerr

2011-08-09 11:50:21 EDT

Build Identifier: 20110218-0911

In our RCP project, I just discovered by a failing JUnit test that under certain circumstances the 'wrong' class files for org.slf4j.Logger & org.slf4j.LoggerFactory are loaded, causing NoSuchMethodErrors or a NoClassDefFoundError for org.mortbay.log.StdErrLog or in case - this package is also present via another dependency - causing unintended behaviour.

There are collisions between the aforementioned jetty package and slf4j providing impls for the two classes org.slf4j.Logger and ~.LoggerFactory.

Workarounds: When the same test is started as 'JUnit Plugin Test' the order of the two colliding plugins (the jetty one and the one offering org.slf4j) does not matter - the correct implementation is found by the framework and the NoSuchMethodError etc. cannot be observed.

Hence, I have two workarounds, either change the order in the manifest or run this test always as plugin test, but both of which (except from being workarounds in the first place) obscure definitely what is going on and do not inhibit future errors of the same kind.


Reproducible: Always

Steps to Reproduce:
1. Define a plugin P containing a single JUnit test T
2. This plugin should have a dependency on a plugin exporting the 'original' org.slf4j package from www.slf4j.org defined in its MANIFEST.MF
3. This plugin should have another dependency on org.eclipse.equinox.http.jetty defined in its MANIFEST.MF
4. The test T should invoke the LoggerFactory.getLogger(Class<T>),  LoggerFactory.getLogger(String) or the LoggerFactory.getILoggerFactory() method.
5. Run the test as JUnit test, and then swap the order of the plugin dependencies in the MANIFEST.MF -> NoSuchMethodError and/or NoClassFoundDefError for org.mortbay.log.StdErrLog.
(6. Run the test as JUnit Plugin test, and then swap the order -> both possibilities are okay.)

Comment 1 Simon Kaegi

2011-08-09 14:03:36 EDT

Hi Bastian,

The two SLF4J classes packaged with the Jetty server bundle that you mention are not meant to be exported and are really an internal detail meant to handle console logging when running in the Eclipse IDE. This binding is used as a last resort and if there is a version of SLF4J exported by another bundle the Jetty bundle will you it in preference to its internal copy.

If your application is not using OSGi then you have to take control to ensure the class-path is created correctly and the JAR containing the SLF4J packages must appear "before" the Jetty JAR file.

Your two workarounds are reasonable and although I admit what's going on here is a bit obscure what we're doing with SLF4J in this case is the trade-off we meant. I'm going to mark WORKSFORME however that's not to say it's all perfectly elegant and when we update to the new version of Jetty in the current release cycle we'll see if we can find a way to avoid packaging an internal copy of the SLFJ Logger.

Comment 2 Aaron Digulla

2013-02-22 08:41:14 EST

I've stumbled over this today when I checked my classpath with maven-duplicate-finder-plugin.

Can you please move these two files to a new bundle and import it as an optional dependency?