Community
Participate
Working Groups
Local Shells > Launch Shell Select the launched shell, press F5 (Refresh) --> An error dialog pops up saying "Problem Occurred: Resource Changed... (Time of error: [...] Reason: Check the details Error log shows an "Unhandled Event Loop Exception" with following cause: Caused by: java.lang.NullPointerException at org.eclipse.rse.ui.internal.model.SystemRegistry.findFilterReferencesFor(SystemRegistry.java:2751) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(SystemView.java:2109) 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) -----------Enter bugs above this line----------- TM 2.0 Testing installation : eclipse-SDK-3.3 RSE install : workspace FREEZE R2_0 java.runtime : Sun 1.6.0_01-b06 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Windows-local ------------------------------------------------
Created attachment 73545 [details] Refresh shell without NPE After some investigation. When hitting F5 on the shell to refresh a null value is returned for the filterpoolreferencemanager as seen below: line of code where exception is found; SystemRegistry [line: 2843] - findFilterReferencesFor(Object, ISubSystem, boolean): ISystemFilterReference[] refs = subsystem.getFilterPoolReferenceManager().getSystemFilterReferences(subsystem); Now after checking to see if the value is null before executing the line above, simply has the method return an empty array. No NPE is thrown but I have experimented with the shell and executed some simple bash commands then refreshed again. What I got as a result is the attachment. Another point I would like to add, what should happen when the F5 key is hit on the shell? Would it be better if the key was disabled to the user?
I cannot see how you would disable a key? - In the context menu for shells, F5 is not there. Or did you think that the Refresh key would just not do anything in case the selection is a local shell?
Sorry... when I mentioned disabling I meant that the functionality of the F5 key would just do nothing. At this point it seems to be firing of the wrong event if I am not mistaken in which it is attempting to retrieve a filterPoolReferenceManager for a shell throwing a NPE.
Yes the expected result of hitting F5 on a shell node in the RSE Tree is unclear -- what should be refreshed anyways? There is nothing to refresh. Personally I'm not sure how you could hook in a handler for the F5 key that would do nothing for shells specifically, especially if you have a multiselect that happens to include a shell. I think that both should be fixed: * The symptom - since by our API we cannot avoid any external plugin firing a refresh event against a shell, we should not NPE in that case. * The root cause - avoiding the refresh event in our own code seems a good idea. If we cannot avoid the event for whatever reasons (e.g. as I mentioned above) it will not be a problem if the NPE is avoided in the event handler.
Seen the same problem when doing F5 on a dstore or ssh shell. It's not just an NPE being logged to the log, but an actual dialog shows up. It's annoying because when I type "exit" in the shell, the "running shell" overlay in the SystemView is not updated; so I pressed F5 but ended up in the NPE.
The problem must be the way how the refresh event is created. Because the fix for bug 197848 also sends an EVENT_REFRESH with the IServiceCommandShell as source, and the NPE is not seen with that one. So the event handling in SystemView seems ok, but an incorrect event appears to be sent.
Created attachment 75339 [details] Patch fixing the issue Attached patch fixes the issue. Problem was that when a subsystemConfiguration does not support filters, it has no FilterReferenceManager. Consequently, when SystemRegistryis asked for the filterReferences, it must not try finding them if the subsystemConfiguration is known not to have filters. The fix is a simple one-liner; I'm not sure why Rupen got the remote output printed into the SystemView on his version of the fix, but mine version works fine.
Patch committed: [194898] Avoid NPE when doing EVENT_REFRESH_REMOTE on a subsys without filters SystemRegistry.java
