Bugzilla – Full Text Bug Listing
| Summary: | Using Visual Editor can destablize running Eclipse instance | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Oleg Besedin <ob1.eclipse> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | bokowski, cuiran2009, Mike_Wilson, ob1.eclipse, olivier.prouvost, pwebster, yves.yang |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 297824 | ||
| Bug Blocks: | |||
|
Description
Oleg Besedin
Yves, would you be able to help us understand why this makes Eclipse crash? I have tested with the build eclipse-e4-SDK-incubation-I20100718-2115-win32. It works fine with photo demo. But it does have a bug with contact demo. I get the following exception: org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:272) at org.eclipse.core.internal.registry.RegistryObjectManager.getObject(RegistryObjectManager.java:262) at org.eclipse.core.internal.registry.ConfigurationElementHandle.getConfigurationElement(ConfigurationElementHandle.java:26) at org.eclipse.core.internal.registry.ConfigurationElementHandle.getName(ConfigurationElementHandle.java:99) at org.eclipse.e4.ui.internal.workbench.ModelAssembler.processModel(ModelAssembler.java:84) at org.eclipse.e4.tools.ui.designer.E4WorkbenchProxy.init(E4WorkbenchProxy.java:128) at org.eclipse.e4.tools.ui.designer.E4WorkbenchProxy.<init>(E4WorkbenchProxy.java:88) at org.eclipse.e4.tools.ui.designer.E4UIRenderer.createVisuals(E4UIRenderer.java:158) at org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureDesigner.setupDiagram(ConfigureDesigner.java:244) at org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureDesigner.access$1(ConfigureDesigner.java:234) at org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureDesigner$1.runInUIThread(ConfigureDesigner.java:153) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) 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:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) 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:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) In fact, it works only once after the restart of eclipse, no matter with which demo. It works well with the empty application created with e4 wizard. It is strange And it works fine in dev mode. (In reply to comment #2) > org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry > object Oleg, aren't you the one who knows more about InvalidRegistryObjectException than most of us? Any ideas? :-) It seems that, for me, closing Visual Design Editor (VDE) that contains Application.e4xmi from the contacts demo is the point which causes things to break.
Also, I installed the current build in a clean separate location with just SDK + XWT and in that combination VDE does not cause Eclipse to close, it just hangs on the "Loading" screen.
The exact steps for me are:
- Clean install of I20100718-2237;
- Installed all "E4 XWT" from
e4 2010 Updates - http://download.eclipse.org/e4/updates/2010 ;
- Got UI examples from CVS Head;
- In the Package Explorer double-clicked on Application.e4xmi from the contacts demo. VDE will open and mark contents as modified.
- Close VDE, don't save;
- In the Package Explorer again double-click on Application.e4xmi from the contacts demo.
The e4 Visual Design Editor shows an "Invalid Registry Object" error and gets stuck on loading.
The Application.e4xmi from the photo demo seems to work fine as long as we don't try to open contacts demo's XMI. At that point Photo demo's XMI will stop opening too.
(In reply to comment #5) > (In reply to comment #2) > > org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry > > object > Oleg, aren't you the one who knows more about InvalidRegistryObjectException > than most of us? Any ideas? :-) After a quick look... wow... this is scary. The XWT's DesignerReflectionContributionFactory actually installs the bundle from the workspace into the *running* Eclipse instance. The practicular exception happens becuase bundle being installed was not cleaned from the previous VDE run, hence uninstall/install messes up extensions which, at the same time, are run through by the ModelAssembler. In more details: The VDE create a new model using ModelAssembler (which is very much an internal class by the way). The ModelAssembler cycles through model fragments and calls mode processors when it find them in extensions. In this case one of the processors is org.eclipse.e4.demo.contacts.processors.MenuThemeProcessor which XWT loads by installing the contacts bundle into the RUNNING Eclipse instance. It seems that for whatever reason the org.eclipse.e4.demo.contacts bundle is not uninstalled when VDE is closed, so opening XMI for the second time forces one instance of the org.eclipse.e4.demo.contacts bundle to be removed, and another instance to be installed. (Proper bundle cleanup can be prevented by anybody holding a reference to an element inside the bundle.) This causes the extension supplied by the removed bundle org.eclipse.e4.demo.contacts to become invalid, causing the invalid registry object exceptions you see. The way DesignerReflectionContributionFactory operates (loading bundles in the running instance) is extremely scary. If we were properly processing dynamic events, opening XMI from the contacts demo would result in UI supplied by the contacts demo to be added to the running instance. We poorly react to dynamic events in 3.x (hence, the need to restart Eclipse instance after a bundle was added) and we don't do well in this area in e4 at all. I don't really know what to say here, this is approach is inherently unreliable. There is no isolation between running Eclipse instance and bundle containing XMI opened in the editor. There is no guarantee of timely cleanup after editor has been closed. (In reply to comment #7) > (In reply to comment #5) > ... > > The way DesignerReflectionContributionFactory operates (loading bundles in the > running instance) is extremely scary. If we were properly processing dynamic > events, opening XMI from the contacts demo would result in UI supplied by the > contacts demo to be added to the running instance. We poorly react to dynamic > events in 3.x (hence, the need to restart Eclipse instance after a bundle was > added) and we don't do well in this area in e4 at all. I agree with you. There is a bug on this issue: Bug 297824 - [Designer] How to start e4 application in the same JVM as Eclipse. > > I don't really know what to say here, this is approach is inherently > unreliable. There is no isolation between running Eclipse instance and bundle > containing XMI opened in the editor. There is no guarantee of timely cleanup > after editor has been closed. I propose to remove this part of code since VDE doesn't support Theme anyway. I think these codes are useless. (In reply to comment #8) > (In reply to comment #7) > > I propose to remove this part of code since VDE doesn't support Theme anyway. I > think these codes are useless. Sorry, I was wrong. It is about the Processor, not only Theme even in this demo it is used to deal with Theme. I have fixed a problem the class ProjectBundleSession; which install/uninstall the workspace bundle dynamically and puts the ExtensionRegister inconsistence. This change works around the problem. But it is not a final and clear solution. The bundle is loaded in Running eclipse and never released. Any modification on the plugin.xml will be taken into consideration. We need to a solution of the Bug 297824 (In reply to comment #7) > It seems that for whatever reason the org.eclipse.e4.demo.contacts bundle is > not uninstalled when VDE is closed .... Looking at the code, there are no calls at all to uninstall bundles installed for the contents of the VDE editors, ever. Plus, not only the bundle containing XMI installed, but all of its dependencies are installed as well. The OSGi's bundle configuration is cached from run to run (barring other changes in the configuration) so, if other things worked properly, after a user opened a contacts demo XMI once: - the UI from the demo would be added to the development environment - the bundle would be installed until "-clean" is used or environment changed Those things don't happen today because of other bugs/issues, however, we'll be fixing underlying dynamic behaviour in 4.1. (The OSGi cache probably works different in develeopment mode - that might have to do with the comment 4.) (In reply to comment #10) > I have fixed a problem the class ProjectBundleSession That should help with the specific problem in the scenario from the comment 6. That said, you probably realize that this will create another problem: if a developer has a bundle installed in his target and decides to modify the bundle in his workspace and see resulting XMI, the unmodified bundle from the target will show up. (In reply to comment #11) > (In reply to comment #7) > > It seems that for whatever reason the org.eclipse.e4.demo.contacts bundle is > > not uninstalled when VDE is closed .... > > Looking at the code, there are no calls at all to uninstall bundles installed > for the contents of the VDE editors, ever. I have tried to do it in the class ProjectBundleSession. Unfortunately, once the bundle is uninstalled, RegistryObjectManager losts all information in the cache. > > Plus, not only the bundle containing XMI installed, but all of its dependencies > are installed as well. > > The OSGi's bundle configuration is cached from run to run (barring other > changes in the configuration) so, if other things worked properly, after a user > opened a contacts demo XMI once: > - the UI from the demo would be added to the development environment > - the bundle would be installed until "-clean" is used or environment changed > > Those things don't happen today because of other bugs/issues, however, we'll be > fixing underlying dynamic behaviour in 4.1. (The OSGi cache probably works > different in develeopment mode - that might have to do with the comment 4.) > In fact, the comment 4 is wrong. I succeeded in the reproduction in dev workbench. > > (In reply to comment #10) > > I have fixed a problem the class ProjectBundleSession > > That should help with the specific problem in the scenario from the comment 6. > That said, you probably realize that this will create another problem: if a > developer has a bundle installed in his target and decides to modify the bundle > in his workspace and see resulting XMI, the unmodified bundle from the target > will show up. VDE is developed initially to work directly with application.e4xmi, since we need a solution to start e4 application in a separate OSGi context in the same JVM (it is the purpose of Bug 297824). Now we reach the limitation with the Processor in EP. We need some helps on this issue. This bug is now out of date -> Closed it |