Community
Participate
Working Groups
Created attachment 217119 [details] 4 test bundles that demonstrate the bug I have the following scenario: Bundle A provides PartStack Bundle B contributes a Part to the above stack (using extension org.eclipse.e4.workbench.model) First start (loading model from e4xmi) works perfect. Second start with with persisted model throws a NPE: java.lang.NullPointerException at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.showTab(LazyStackRenderer.java:156) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1024) at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:98) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:639) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:725) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:696) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:690) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:675) at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:59) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:635) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:725) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:696) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:690) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:675) at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:59) at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.processContents(WBWRenderer.java:626) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:635) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:725) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:696) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:690) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:675) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:961) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.start(E4Application.java:150) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) To test it, run all the 4 bundles from the attachment (ignore the property errors, I did not provide the login and renderer classes). - First start works - Second start throws NPE
Kai, I've found the issue (but not the solution..;-)... On the first load all is well as you say...let's call the details part 'D1' When we write it out D1 is the child of the 'details' part stack. More important the *selected element* of the 'details' part stack is D1. Now, on the second load the 'fragment.Merge()' method (ModelAssembler line 167) seems to replace the existing D1 with the new one D2 (which seems OK to me as well, better than having two). However, the stack's selected element is left referencing D1 (which at this point has no container, leading to the NPE). Patch coming...
Created attachment 217175 [details] Patch that updates the parent's selected element if necessary
Note that this is really a hack... The original problem points out that the current fragments strategy needs real work if we hope to use it in any general sense. This was a relatively simple containment reference but *every* place in the model that there's a reference to some other element should be checked. For example I suspect that you'll get a new and exciting bug were you to replace an MPart in a Window's 'sharedParts' list because any existing MPlaceholder references would not be updated... IMO, until we've addressed the analysis (at least) we should *not* promote this as API.
Thanks Eric, are you planning to push the patch to the git master? Would this be a blocker for Juno?
(In reply to comment #4) > Thanks Eric, are you planning to push the patch to the git master? > Would this be a blocker for Juno? No, probably for SR1 PW
on the second start the merge should not be executed or am I wrong.
see Bug 389624 for a more general approach using UsageCrossReferencer to update all other references to an objectToBeReplaced see Bug 389663 on the question, if the fragments should be loaded at this time at all
*** This bug has been marked as a duplicate of bug 389624 ***
