Community
Participate
Working Groups
Created attachment 173092 [details] full log, but not much more than what I copied From no deltas, I used quick access to switch the the team sync perspective and then back to java perspective. Then I used quick access to open the console view, and next when I tried to open the error log I got an NPE. !ENTRY org.eclipse.e4.ui.workbench 4 0 2010-06-30 09:11:24.160 !MESSAGE Internal Error !STACK 0 java.lang.NullPointerException at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:361) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:577) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:635) at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:678) at org.eclipse.ui.internal.WorkbenchPage$7.run(WorkbenchPage.java:2327) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:2324) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:2300) at org.eclipse.ui.internal.quickaccess.ViewElement.execute(ViewElement.java:38) at org.eclipse.ui.internal.quickaccess.SearchField$1.handleElementSelected(SearchField.java:47) at org.eclipse.ui.internal.quickaccess.QuickAccessContents.handleSelection(QuickAccessContents.java:324) at org.eclipse.ui.internal.quickaccess.QuickAccessContents.access$0(QuickAccessContents.java:314) at org.eclipse.ui.internal.quickaccess.QuickAccessContents$1.keyPressed(QuickAccessContents.java:343)
It failed because it was also opening the views in the team sync perspective. When I switch back to the team sync perspective, it has both the console and error log views open in it. PW
Both claims confirmed in my inner.
You don't even need to open the 'Console' view. Just go straight for the 'Error Log' view and the NPE will occur.
For whatever reasons, the workbench window's EPS is not being updated with the 'Java' perspective as its root. Instead, it's still using the previous perspective (in this case, the 'Team Synchronize' one).
The 'Console' view shows up in both perspectives because the 'Java' perspective actually has a placeholder for the 'Console' view. So the part service first shows the 'Console' view in the (incorrect) 'Team Synchronize' perspective, then farther down in the code, we try to activate the 'Console' view in the 'Java' perspective. Since a placeholder is actually there, it is found and that operation completes successfully. There are no placeholders for the 'Error Log' in the 'Java' perspective so we get an NPE back for our troubles.
This is apparently caused (somehow) by the 'uninject' code introduced to the PartRenderingEngine yesterday. At least commenting the code out seems to resolve some number of the issues. My best guess is that the un-inject is executing some computation (specifically the context function that sets the 'rootContainer' for the window's context) in a manner that causes it to not 'get' any context values. Remy has observed that after the first context switch it never seems to fire for the *window* even though other ones correctly update the 'rootContainer' on a perspective switch.
Oleg, where's the code that will remove a 'stale' computation? I'd like to see whether or not my comments reflect any sort of reality...;-).
Committed in >20100630. I've commented out the call to 'uninject' in the PartRenderingEngine#removeGui for now since it seems to solve at least this (and perhaps other) issues. Once the 'uninject' code is fixed we should un-comment the code in the PRE (otherwise I expect that we will have multiple PerspectiveSwitcher listeners firing against ones that have been removed...
Created attachment 173139 [details] Tests patch to reproduce the problem Having problems trimming this down further but this will do I suppose.
Committed in >20100630. I've hacked the PerspectiveSwitcher to remove its subscribed listeners on the 'comp' widget being disposed as opposed to relying on @PreDestroy. This should be safe since 'unsubscribe' is a no-op if the listener hasn't been registered so calling it twice isn't an issue. Without this we would likely run into issues with 'stale' switchers attempting to react to events after they've been removed from the UI.
Created attachment 173140 [details] Tests patch to reproduce the problem v2 This includes the original test from the previous attachment and a more condensed version.
Created attachment 173149 [details] Patch for context injection Patch fixes JUnits. (Patch for the context injection applied to CVS Head.)
*** Bug 317183 has been marked as a duplicate of this bug. ***
Created attachment 173154 [details] Patch for duplicate calls in uninject This also uncovered duplicate calls in #uninject(). (Patch applied to CVS Head.)
*** Bug 318445 has been marked as a duplicate of this bug. ***
Using SDK 4.0 - I20100701-1105 my issue (bug 317183) which was marked as dup of this one seems almost fixed: there's still 'Last Edit Location' which is enabled out of the box but shouldn't.
(In reply to Paul Webster from comment #0) > Created attachment 173092 [details] > full log, but not much more than what I copied > > From no deltas, I used quick access to switch the the team sync perspective > and then back to java perspective. Then I used quick access to open the > console view, and next when I tried to open the error log I got an NPE. Works for me in Luna. Marking as WORKSFORME
