Community
Participate
Working Groups
I20130402-0800 A bad "Unable to find Action Set: <id>" message is written to the log after a plug-in with an actionSet has been removed. Removing a plug-in is a normal operation that must not result in log entries. When fixing this bug, make sure you not only remove the log entry, but also dangling references in the E4 model. Steps: - new workspace - create a new Plug-in Project "P", using the "Hello, World" template - Run As > Eclipse Application - close Welcome - close the runtime workbench - close the project P - run the Eclipse Application again => Bad log entry: !ENTRY org.eclipse.ui 4 4 2013-04-09 17:34:53.704 !MESSAGE Unable to find Action Set: P.actionSet
Does not happen in 3.8, but happens in 4.2.1 as well.
This is much worse than I initially thought. Even more extension point contributions stay active after a plug-in is removed from an install. Example: Have org.eclipse.ui.tests in your workspace. Start a clean runtime workspace, close it again, and then close the org.eclipse.ui.tests project. When you now restart the runtime, you not only get "Unable to find Action Set" messages, but also key bindings that were defined by o.e.ui.tests are still active! Now, I can't type a '*' character any more, since Shift+8 gives me a "conflicting key binding chooser" popup for the org.eclipse.ui.bindings contributions from the long-gone test plug-in.
Created attachment 233662 [details] example P/plugin.xml (In reply to comment #2) I confirmed this is not an issue with the sequenceModifier element (not used in production, bug 296927). You get the same bug when you create a new plug-in project "P", use the "Hello, World Command" template, and then create a similar conflict as shown in the attachment.
I'll look at the keybindings in bug 406003 The actionSets I'll look at here. PW
We want to persist the fact the actionSet is on when a plugin is removed and re-added. The warning message shouldn't have been there. https://git.eclipse.org/r/15622 bug 406003 was a real problem with the keybindings we saved in the model. PW
The leftover actionSet and individual bindings from plugins are now fixed for 4.3.1. The rest of the changes are more significant and risky, so I've deferred the rest of this work until Luna. PW
(In reply to Paul Webster from comment #6) > The rest of the changes are more significant and risky, so I've > deferred the rest of this work until Luna. What is still open? We fixed dangling part descriptors based on model fragment and processors in Bug 445663. Markus reported about ActionSets which you said are fixed.
I have some old handlers which simply won't go away: <handlers xmi:id="_y03YwmgBEeSBSJt6OFoplQ" elementId="org.eclipse.e4.tools.css.spy.OpenSpyHandler" contributorURI="platform:/plugin/org.eclipse.e4.tools.css.spy" contributionURI="bundleclass://org.eclipse.e4.tools.css.spy/org.eclipse.e4.tools.css.spy.OpenSpyHandler" command="_y05QDGgBEeSBSJt6OFoplQ"/> <handlers xmi:id="_y03Yw2gBEeSBSJt6OFoplQ" elementId="org.eclipse.e4.tools.css.spy.OpenScratchpadHandler" contributorURI="platform:/plugin/org.eclipse.e4.tools.css.spy" contributionURI="bundleclass://org.eclipse.e4.tools.css.spy/org.eclipse.e4.tools.css.spy.OpenScratchpadHandler" command="_y05QDWgBEeSBSJt6OFoplQ"/> <handlers xmi:id="_y03YxGgBEeSBSJt6OFoplQ" elementId="org.eclipse.e4.tools.spy.handler" contributorURI="platform:/plugin/org.eclipse.e4.tools.spy" contributionURI="bundleclass://org.eclipse.e4.tools.spy/org.eclipse.e4.tools.spy.SpyHandler" command="_y05QP2gBEeSBSJt6OFoplQ"/> As far as I can guess, these are because I have pulled and built a new version of the plugin in question which changed the names of the handler classes while the version of the plugin didn't change. This causes the following exception and another like it during startup: java.lang.ClassNotFoundException: org.eclipse.e4.tools.css.spy.OpenScratchpadHandler cannot be found by org.eclipse.e4.tools.css.spy_0.12.0.qualifier at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:573) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:73) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:55) at org.eclipse.e4.ui.internal.workbench.addons.HandlerProcessingAddon.processActiveHandler(HandlerProcessingAddon.java:144) at org.eclipse.e4.ui.internal.workbench.addons.HandlerProcessingAddon.postConstruct(HandlerProcessingAddon.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:888) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:120) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:337) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:271) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:186) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:107) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:73) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:50) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:277) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:604) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:582) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
(In reply to Timo Kinnunen from comment #8) > I have some old handlers which simply won't go away: Markus, are you OK to use this bug report to work on the removal of handlers which points to invalid classes or is this bug bigger?
(In reply to Lars Vogel from comment #9) > Markus, are you OK to use this bug report to work on the removal of handlers > which points to invalid classes or is this bug bigger? This bug is now the umbrella bug for problems caused by E4 model caches that are not updated when plug-ins are updated or removed. Dangling handler class references is just one of the remaining problems. See the "Depends on" field for more.
Too late for 4.5.2.
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
Moving target milestone to 4.9 for all bugs that are major or above.
This bug doesn't seem to have enough interest to get into 4.10 nor even 4.11. Removing target version. Whoever who is ready to work on it can set the target version according to their goal and planning.
See also DynamicPluginsTestSuite for test for (all) mentioned problems with dynamically enabling and disabling of plug-ins. This test suite was disabled somewhere in the E4 development cycle due to many failing test...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
