Community
Participate
Working Groups
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.)
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.
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?
