Community
Participate
Working Groups
- Launch RSE 2.0 - Expand Locals node - Select Local Shells - Use keyboard shortcut F5 to refresh node - Unhandled exception in event loop is thrown org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.AssertionError: EVENT_REFRESH_REMOTE outside subsystem) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:126) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) 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:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144) Caused by: java.lang.AssertionError: EVENT_REFRESH_REMOTE outside subsystem at org.eclipse.rse.internal.ui.view.SystemView.refreshRemoteObject(SystemView.java:2903) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(SystemView.java:2170) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) ... 23 more
Uwe - why do you think this is major? I cannot see any major loss of functionality, at the most a dialog pops up that the user can click away, so I'm reducing to severity normal. Leaving P2 for now unless you can confirm that this is not urgent. I guess the interesting part of the backtrace is this, and we need to understand why refreshing on a Shell Subsystem tries to fire an EVENT_REFRESH_REMOTE: Caused by: java.lang.AssertionError: EVENT_REFRESH_REMOTE outside subsystem at org.eclipse.rse.internal.ui.view.SystemView.refreshRemoteObject(SystemView.java:2903) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(SystemView.java:2170)
If you do something such simple and exceptions are thrown, that is always major. You cannot do what you want to do and you have major loss of functionality as the requested functionality is not executed. IMHO "normal" is to low for everything like this, but it is your call.
Ok, I see your point... Not being able to refresh the Shell Subsystem may not be much of an issue, but not being able to refresh a custom debugger subsystem is an issue. But I cannot reproduce your problem on TM 2.0 -- tried the Local Shell, Local Files, DStore Files/Processes/SHell both while connected and unconnected, even the Tests and Daytime and all worked fine. Only problem I found was a different NPE than yours when trying to refresh a local shell (filed as bug #194898). What version of RSE did you test? Can you try reproducing with the 2.0 Release? Could this be an issue with your own extension on top of RSE?
>What version of RSE did you test? Can you try reproducing with the 2.0 Release? CVS HEAD version. Should be == 2.0, shouldn't it? >Could this be an issue with your own extension on top of RSE? Nope. Because I used a RSE only workspace and target platform.
Hm... 4 fixes went into rse.ui yesterday: bug 192716, bug 177587, bug 182403, bug 187707. Since I cannot reproduce it on R2_0, could you try select rse.ui and Team > Switch to another branch or version > R2_0 and see if you can still reproduce it? If not, then one of the four bugs mentioned introduced a regression.
Falling back to R2_0 of org.eclipse.rse.ui. Same issue.
I can't reproduce this on my dev driver.
I can reproduce this in my dev driver and rse 2.0, if I create a Local Shell and press F5 on that shell. Pressing F5 on "Local Shells" doesn't give me an error.
I think what you see by doing F5 on a Shell is bug #194898 and not this one -- did you compare the backtraces seen?
Martin, what I described is bug #194898. Thought I had already posted this after making my initial post.
Ok, now I know why I first could not reproduce it: The exception is only seen when launching in the debugger, and on the Launch Configuration's 2nd tab ("Arguments") the following is entered: Program Arguments: -debug VM Arguments: -ea -esa In other words, the application needs to be launched with assertions enabled. I'd recommend every TM developer / committer change his launch configurations to enable assertions as mentioned above.
After following Martin's suggestion, I hit the assert exception. What's happening is that on remote refresh, we're getting the parent of the subsystem (the IHost) and calling refreshRemoteObject() on it. The code expects there to be an associated subsystem, but for an IHost, the view adapter returns null hence the failed assertion.
I guess the bug is that when refreshing a subsystem, we should NOT refresh the parent instead. Same when refreshing a host -- if I'm not mistaken there is a separate bug saying that "Refresh All" is done for refresh on a host.
I don't think we should be doing a refresh remote for non-remote things like subsystems. That's not what that event was intended for. For now, I will make sure that non-remote objects don't go into refreshRemoteObject().
I take that back, a subsystem could contain remote objects directly (as opposed to via filters) so we'll need to keep the refreshRemoteObject for subsystems.
I've changed this to not refresh on the parent if the object is a subsystem. I've committed this to cvs.
