Community
Participate
Working Groups
Version: Indigo: SDK + m2e + egit + Jubula org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V) at org.eclipse.swt.SWT.error(SWT.java:4282) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3935) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3612) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.SLF4JLocationAwareLog.error(SLF4JLocationAwareLog.java:225) at org.eclipse.jubula.client.ui.Plugin$5.run(Plugin.java:1094) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) ... 22 more
I am not able to reproduce this error. I use Indigo SDK + m2e + egit + Jubula. After installing all the features I am able to connect to the embedded DB, connect with the AUT-Agent, start an AUT, write and execute tests. It would be helpful if you could provide more information about the actions you performed before this error occured.
I tried again from scratch with the following things installed and I can reproduce the issue Eclipse SDK 3.7.0.I20110603-0909 org.eclipse.sdk.ide Jubula 1.0.0.201106060803 org.eclipse.jubula.feature.feature.group m2e - Maven Integration for Eclipse 1.0.0.20110607-2117 org.eclipse.m2e.feature.feature.group m2e - slf4j over logback logging (Optional) 1.0.0.20110607-2117 org.eclipse.m2e.logback.feature.feature.group It happens when I hit the "Connect to Aut Agent" button in the toolbar
Jubula: 1.0.0.201106060803 Eclipse: 3.7.0.I20110613-1736 M2E: 1.0.0.20110607-2117 AJDT: 2.2.0.e37x-20110711-1300 OS: Mac OS last patch level Same on my system. This bug is spamming my log file and I have to kill the eclipse process. After restart, eclipse will use 100% CPU to build the workspace (this is very unusual on my system). I have to wait until workspace build is finished. If I'm to quick with editing it get stalled again. Its driving me crasy. It happens randomly, while editing / saving a java / aspectj files. After removing Jubula every thing works fine. By the way I installed Jubula just to have a look on it, but never have (because no time yet) -- so never used it. Perhaps that helps.
I observe same behavior with Eclipse: 3.7.0.I20110613-1736 Jubula: 1.0.0.201106060803 among others I also see the main error org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V) surprisingly on a fresh Eclipse installation with only Jubula plug-in added (versions above) it works tried to investigate further and discovered the following the org.slf4j.api plug-in included in jubula bundle (version 1.5.11.v20100519-1910) is not referenced explicitly by bundle org.eclipse.jubula.tools (minimum version 1.5.11 inclusive, but no maximum, not explicit versioning here) in another Eclipse installation I examined, for which Jubula is not functioning properly, there are 2 installed versions of org.slf4f.api bundle (1.5.11.v20100519-1910 and 1.6.1.v20100831-0715) I suspect that the underlying OSGI framework selects the latest one (1.6.1 here) which has a different API contract for the method org.slf4j.spi.LocationAwareLogger.log in org.slf4j.api bundle 1.5.11.v20100519-1910 the contract is void log(org.slf4j.Marker arg0, java.lang.String arg1, int arg2, java.lang.String arg3, java.lang.Throwable arg4); while in org.slf4j.api bundle 1.5.11.v20100519-1910 the contract is void log(org.slf4j.Marker arg0, java.lang.String arg1, int arg2, java.lang.String arg3, java.lang.Object[] arg4, java.lang.Throwable arg5); I think what's missing is strict versioning in org.slf4j.api dependency of org.eclipse.jubula.tools bundle (or any other Jubula bundle referencing org.slf4j.api bundle) please provide a related fix ot plug-in fragment in update-site
a small correction for comment #4 in org.slf4j.api bundle 1.5.11.v20100519-1910 the contract is void log(org.slf4j.Marker arg0, java.lang.String arg1, int arg2, java.lang.String arg3, java.lang.Throwable arg4); while in org.slf4j.api bundle 1.6.1.v20100831-0715 the contract is void log(org.slf4j.Marker arg0, java.lang.String arg1, int arg2, java.lang.String arg3, java.lang.Object[] arg4, java.lang.Throwable arg5);
I don't know if I am writing in the correct section, I have a similar error using eclipse. I am using Eclipse Indigo Eclipse Java EE IDE for Web Developers. Version: Indigo Release Build id: 20110615-0604 with jdk 1.5.0.22. OS: opensuse 11.2 The error is the same if I change the jdk to jdk 1.6.0.21
For users experiencing problems on Mac OS X: Could you check if there is a modal dialog in the background preventing to return back to Eclipse?
I think comment #4 and comment #5 summarize the situation pretty well, with the additional twist that some parts of Jubula use JCL over SLF4J. This is what makes Jubula's logging so version-dependant: That JCL over SLF4J (the org.slf4j.jcl bundle) seems to depend on the specific version of SLF4J. I suggest getting rid of the JCL over SLF4J dependencies and using only the org.slf4j.api bundle. Until a fix is ready, a possible workaround might be to find and install the org.slf4j.jcl bundle in the corresponding version (e.g. 1.6.1).
correct me if I am wrong but, the problem still remains at the strict dependency of slf4j API bundle not the underlying implementation (JCL or other) I believe installing org.slf4j.jcl 1.6.1 bundle wouldn't offer a resolution because the incorrect slf4j API bundle (1.6.1) would still be referenced it seems the only compatible slf4j API bundle is 1.5.1 (originally supplied with Jubula feature) API contract of slf4j 1.6.1 will still differ making slf4j API inaccessible in Eclipse installations containing slf4j API bundle 1.6.x or newer (from other features) Jubula access to slf4j API will keep failing unless either Jubula starts using newer slf4j API or locks itself to a compatible version 1.5.1 (original one)
Keep in mind that org.slf4j.jcl is *not* an implementation bundle. It is a drop-in replacement for JCL that delegates to org.slf4j.api. http://www.slf4j.org/legacy.html has a better description of this than I can provide. Although I have not tried the proposed workaround, I do believe that it will work because the highest available version of org.slf4j.jcl will be 1.6.1, and I would expect this version of org.slf4j.jcl to be compatible with org.slf4j.api 1.6.1. org.slf4j.spi.LocationAwareLogger is never directly referenced from Jubula code; it is only referenced via calls to org.slf4j.jcl. Of course, the proposed workaround is not a long-term solution. But it should ease the pain until we can resolve the issue itself. With regards to the long-term, I still think that removing all references to org.slf4j.jcl is the best solution. Once Jubula is logging by directly calling methods from the org.slf4j.Logger interface, nothing short of a *major* API change should break it. That being said, setting an upper bound (something like 2.0.0 exclusive) on the org.slf4j.api dependency should guard against that extreme case.
I understand, Jubula calls JCL which calls slf4j I believe your proposal could work as a short-term solution however, guarding the upper bound on the org.slf4j.api dependency is a safer and at the same time permanent resolution (until either JCL is replaced by direct calls to org.slf4j.Logger etc.)
I get the same error on Linux. What makes me wonder is although Jubula is installed I am not actively using it. Why does Jubula fill my error log with these exceptions anyway? Should it not be dormant until being used?
I was able to reproduce this error using Indigo by updating the org.slf4j.api bundle to 1.6.1. Eclipse/Jubula did not react to any commands and could not be closed. After updating the SLF4J JCL to 1.6.1 this error does not occur anymore.
Unified "org.slf4j.api" usage for all Jubula bundles http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=cce048792ee9b6f9b224015a89f84080e72022d5
Fix verified using latest Jubula nightly build. Updating the org.slf4j.api bundle to 1.6.1. does not lead to the described errors anymore.
Having the same issue here. Where do I find the Jubula nightly update site? Thank you in advance.
*** Bug 357123 has been marked as a duplicate of this bug. ***
*** Bug 357601 has been marked as a duplicate of this bug. ***
*** Bug 360167 has been marked as a duplicate of this bug. ***
I installed Jubula from the Juno update site yesterday and still got this problem. Is this to be expected?
Yes, this is to be expected with Juno M2. At the moment, we still deliver Jubula 1.0 with Juno (whereas we delivered Jubula 1.1 with Indigo SR1). We expect to update the Jubula version for Juno M4.
JFTR, installing Jubula on an Indigo SR1 installation alongside with the latest Xtext SDK seems to break it as well: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V at org.apache.log4j.Category.differentiatedLog(Category.java:178) at org.apache.log4j.Category.info(Category.java:221) at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:105) ... Uninstalling Jubula fixes the issue, but that's not a permanent solution. Will this be fixed by the Jubula fix some time in the distant future or is this something that the Xtext developers need to look into as well?
(In reply to comment #22) > JFTR, installing Jubula on an Indigo SR1 installation alongside with the latest > Xtext SDK seems to break it as well: > > java.lang.NoSuchMethodError: > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V > at org.apache.log4j.Category.differentiatedLog(Category.java:178) > at org.apache.log4j.Category.info(Category.java:221) > at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:105) > ... Do you get the problem if you install m2e and Xtext?
(In reply to comment #23) > (In reply to comment #22) > > JFTR, installing Jubula on an Indigo SR1 installation alongside with the latest > > Xtext SDK seems to break it as well: > > > > java.lang.NoSuchMethodError: > > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V > > at org.apache.log4j.Category.differentiatedLog(Category.java:178) > > at org.apache.log4j.Category.info(Category.java:221) > > at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:105) > > ... > > Do you get the problem if you install m2e and Xtext? I've got the following features installed: Maven Integration for Eclipse (Required) 0.12.1.20110112-1712 org.maven.ide.eclipse.feature.feature.group Sonatype, Inc. m2e - slf4j over logback logging (Optional) 1.0.100.20110804-1717 org.eclipse.m2e.logback.feature.feature.group Eclipse.org - m2e and no problems so far - does that count?
(In reply to comment #22) > JFTR, installing Jubula on an Indigo SR1 installation alongside with the latest > Xtext SDK seems to break it as well: > > java.lang.NoSuchMethodError: > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V > at org.apache.log4j.Category.differentiatedLog(Category.java:178) > at org.apache.log4j.Category.info(Category.java:221) > at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:105) > ... > > Uninstalling Jubula fixes the issue, but that's not a permanent solution. Will > this be fixed by the Jubula fix some time in the distant future or is this > something that the Xtext developers need to look into as well? I think this is something that the Xtext developers will need to look into. I see from the stack trace that Xtext code that is calling log4j (which is then calling slf4j) is throwing the exception. This is very similar to the problem that Jubula was causing. I'm thinking that the org.slf4j.log4j bundle is to blame in this case (i.e. the highest available versions of org.slf4j.log4j and org.slf4j.api do not match).
