Community
Participate
Working Groups
Saw this on startup: org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4300) at org.eclipse.swt.SWT.error(SWT.java:4215) at org.eclipse.swt.SWT.error(SWT.java:4186) at org.eclipse.swt.widgets.Widget.error(Widget.java:466) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404) at org.eclipse.swt.widgets.Tree.getSelection(Tree.java:1714) at org.eclipse.jface.viewers.TreeViewer.getSelection(TreeViewer.java:256) at org.eclipse.jface.viewers.AbstractTreeViewer.getSelection(AbstractTreeViewer.java:2944) at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager.initializeViewerSelection(FocusedViewerManager.java:451) at org.eclipse.mylyn.internal.context.ui.ContextUiPlugin.lazyStart(ContextUiPlugin.java:244) at org.eclipse.mylyn.internal.context.ui.ContextUiPlugin.initLazyStart(ContextUiPlugin.java:210) at org.eclipse.mylyn.internal.context.ui.ContextUiPlugin.start(ContextUiPlugin.java:202) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:463) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:268) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:52) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:264) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition$1.run(LightweightDecoratorDefinition.java:124) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.internalGetDecorator(LightweightDecoratorDefinition.java:120) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:251) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:370) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:330) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
*** Bug 366388 has been marked as a duplicate of this bug. ***
*** Bug 367666 has been marked as a duplicate of this bug. ***
This has become a lot worse for us with the current 3.7 version. The cause appears to be that the changes introduced in c831c5c6b2861 (NEW - bug 352915: extract test support classes into sdk bundles https://bugs.eclipse.org/bugs/show_bug.cgi?id=352915) prevent the context.ui bundle to be started when the first task is activated due to moving org.eclipse.mylyn.internal.context.tasks.ui.TaskActivityMonitor to a different bundle.
Carsten, do you have the o.e.m.context.tasks.ui bundle in your installation? This is now required to ensure that context UI is initialized on task activation.
Yes I do and I see its activation. However, activation of context.ui does not happen until the DecorationScheduler runs and loads the decorator extension from there. Before the change, this happened during first task activation when the TaskActivityMonitor class was loaded. As far as I can see, the threading problem is a followup issue of that.
Part of the problem is that the code in assumes ContextUiPlugin.lazyStart() assumes that it is invoked on the UI thread which is not the case. I can wrap the call to the viewer initialization in a Display.asyncExec() to fix that. I am wondering though if there are any other issues that you are seeing due to the lazier initialization?
So far this seems to be the only issue I noticed. I think an asyncExec() might be a good idea. Additionally, triggering the ContextUI.lazyStart() by way of the decorator seems a bit brittle and random to me. So I'd suggest explicitly triggering it, e.g. in TaskActivityMonitor.CONTEXT_TASK_ACTIVATION_LISTENER.taskActivated() or preTaskActivated(). I'm currently using the taskActivationListeners extension point with preTaskActivated() in our own client code to start context.ui to work around the issue. This works quite well so far.
Thanks for pointing that out. I pushed f434554eaaa7098132b06e7178af63e4d15ecca1 to fix this. o.e.m.context.ui is now explicitly activated. Arguably this should be triggered by o.e.m.context.core but I didn't want introduce another extension point at this point. I have triggered a new weekly build. Please reopen in case you are still experiencing problems after updating to the latest.
