Bug 378815 - Need better story for handling model elements that should disappear on startup
Summary: Need better story for handling model elements that should disappear on startup
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.2   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: 4.11 M3   Edit
Assignee: Christian Pontesegger CLA
QA Contact:
URL:
Whiteboard: noteworthy
Keywords:
: 388173 485454 (view as bug list)
Depends on:
Blocks: 569777 509371 511518 544490 544871
  Show dependency tree
 
Reported: 2012-05-08 07:19 EDT by Markus Keller CLA
Modified: 2020-12-17 07:33 EST (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2012-05-08 07:19:04 EDT
Log entry on startup on 10.6.8:

eclipse.buildId=I20120503-1800
java.version=1.6.0_31
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86, WS=cocoa, NL=en_US
Framework arguments:  -keyring /Users/eclipse/.eclipse_keyring -showlocation
Command-line arguments:  -os macosx -ws cocoa -arch x86 -keyring /Users/eclipse/.eclipse_keyring -showlocation

Error
Tue May 08 12:54:46 CEST 2012
Unable to load class 'org.eclipse.e4.ui.workbench.renderers.swt.cocoa.DisengageFullscreenWindowHandler' from bundle '332'

java.lang.ClassNotFoundException: org.eclipse.e4.ui.workbench.renderers.swt.cocoa.DisengageFullscreenWindowHandler
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340)
	at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:100)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.processHierarchy(E4Workbench.java:170)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.init(E4Workbench.java:118)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.<init>(E4Workbench.java:69)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:302)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:551)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:537)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	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(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	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)
Comment 1 Brian de Alwis CLA 2012-05-08 10:20:08 EDT
Was this workspace run between Apr 29 to May 2?  I'm not sure it's worth adding code to remove stray references introduced within a milestone.

This issue is the one area where the extension-point model story beats the modelled UI story: handling things that disappear.
Comment 2 Markus Keller CLA 2012-05-08 11:53:41 EDT
> Was this workspace run between Apr 29 to May 2?

Yes, I think it was. I don't see the exception in other workspaces that were not run which such a build.

> This issue is the one area where the extension-point model story beats the
> modelled UI story: handling things that disappear.

Feel free to reuse this bug for a more general problem. Even if this concrete exception doesn't happen any more, I assume this can still happen in other scenarios and needs a general solution.
Comment 3 Paul Webster CLA 2012-05-08 13:22:06 EDT
(In reply to comment #1)
> Was this workspace run between Apr 29 to May 2?  I'm not sure it's worth adding
> code to remove stray references introduced within a milestone.
> 


We should at least look into the various places things can disappear.  Classes that can be loaded are one.  Menu items contributed from plugins?

PW
Comment 4 Brian de Alwis CLA 2012-06-04 07:33:35 EDT
Questions coming up about how to remove items so that they aren't persisted in the model,

http://www.eclipse.org/forums/index.php/mv/msg/358388/881071/

Perhaps we should have a transient tag or flag that is used on persisting items to disk.
Comment 5 Brian de Alwis CLA 2012-08-28 10:10:52 EDT
*** Bug 388173 has been marked as a duplicate of this bug. ***
Comment 6 Eric Moffatt CLA 2012-08-28 11:55:20 EDT
There are two different scenarios in which bundles may be unavailable for a given session; they've been uninstalled or you're opening an old workspace with a new eclipse install and haven't re-installed the bundles.

Because of the second case it's very desirable to maintain the model in it's original state and show error parts / zombie perspectives etc so that once the user re-installs the bundles everything comes back. This most likely should include (for example) checking whether the bundle for an Addon's implementation is available and silently ignoring it if not.

We do keep at least some tack of where contributions come from, perhaps we should have a UI Model equivalent to 'lint' that will explicitly remove elements from the model if the contributing bundles aren't around any more.

NOTE: the PHD version of this for Addons is a bit more complex; they need some sort of addon specific 'uninstall' step or some way to link model artifacts to the addon that created them. The scenario to think about here is the MinMaxAddon where the MToolControls backing minimized stacks should be removed if the addon is uninstalled. This is a 'leak' issue, the stacks would likely never be rendered but they'd linger in the model past their useful life.
Comment 7 Jeeeyul Lee CLA 2012-08-28 20:21:32 EDT
There is another scenario:
* A bundle should be updated and provide old add-on no more because of deprecation or some reason.
Comment 8 Joseph Carroll CLA 2012-08-29 08:46:05 EDT
What about adding a simple "Clear Workbench History" check box on the startup dialog?

Like when you switch workspaces, it gives you the option to copy and some others, maybe the answer is to include an "Advanced Tab" that is collapsible and one of the options is CWH.  I could even work something up that looked for any error log in the selected workspace that lists whether the workbench shutdown properly.  If it didn't it could say something like start in "Safe Mode".

Thoughts?


JD
Comment 9 Brian de Alwis CLA 2016-01-26 16:27:59 EST
*** Bug 485454 has been marked as a duplicate of this bug. ***
Comment 10 Christian Pontesegger CLA 2017-01-26 06:14:39 EST
Asking for a story for this feature, here is one:

EASE allows to execute scripts within Eclipse. Through a simple API we allow users to add toolbar/menu contributions for such scripts. So we constantly monitor scripts for some context data and dynamically create eg toolbar buttons for the UI. Currently we use ContributionFactories for that. I just experimented with the e4 model which would provide nicer means to customize the UI dynamically. But currently those dynamic changes get persisted. After a restart some scripts - eg located on a network share - might have changed or disappeared. But the persisted toolbar entries are still there and would require manual cleanup.
I want to mark such contributions as transient, so they do not get persisted. It would be great if that would even apply for closing and reopening views, but it would be sufficient for closing and restarting the application.

Further we are experimenting with pure dynamic viewparts created programmatically through scripts. When restored after an eclipse restart they remain empty parts. Would be great if we could mark them as non-persitent.
Comment 11 Eclipse Genie CLA 2018-10-29 09:27:11 EDT
New Gerrit change created: https://git.eclipse.org/r/131595
Comment 12 Christian Pontesegger CLA 2018-12-18 09:47:20 EST
Hi,
I have filed a patch for this issue. Would be great if you could have a look, thanks.
Comment 14 Lars Vogel CLA 2019-02-12 10:37:48 EST
Brian or Christian please add to the N&N for 4.11.
Comment 15 Christian Pontesegger CLA 2019-02-12 13:11:02 EST
any link where to add a note about this feature?
Comment 16 Lars Vogel CLA 2019-02-12 13:27:21 EST
Git repo: ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git
Gerrit: ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git
The rolling N&N content for 4.11:  https://www.eclipse.org/eclipse/news/4.11
Comment 17 Eclipse Genie CLA 2019-02-12 14:33:15 EST
New Gerrit change created: https://git.eclipse.org/r/136794
Comment 18 Christian Pontesegger CLA 2019-02-12 14:33:24 EST
Added https://git.eclipse.org/r/#/c/136794/
Please adapt as appropriate
Comment 19 Lars Vogel CLA 2019-02-12 15:19:34 EST
(In reply to Christian Pontesegger from comment #18)
> Added https://git.eclipse.org/r/#/c/136794/
> Please adapt as appropriate

Thanks, Christian.
Comment 21 Lars Vogel CLA 2019-02-15 04:00:46 EST
Christian, could you extend this so that also the persisted state of fragment contributions can be used to define this via a new flag? 

Scenario: we have contributions coming from model fragments. If the user uninstalls the corresponding plug-ins, the model contributions remain part of the application model. Therefore, we see errors as for example the images cannot be resolved. 

If we could add the info that these model elements should not be persisted via the persisted state for the contributed model elements, they would be removed once the plug-ins are uninstalled.

To test this scenario, install the e4 spies into a new SDK and uninstall them again. Restart and check the error log.
Comment 22 Christian Pontesegger CLA 2019-02-16 12:18:11 EST
I do understand your use case, but - to be honest - I do not understand what you ask for.

How do you indicate in the fragment model data whether you want to save it or not?
Comment 23 Lars Vogel CLA 2019-02-19 03:31:44 EST
Mass change, please reset target if you still planning to fix this for 4.11.
Comment 24 Eclipse Genie CLA 2019-02-20 05:08:39 EST
New Gerrit change created: https://git.eclipse.org/r/137260
Comment 25 Eclipse Genie CLA 2019-02-20 05:13:36 EST
New Gerrit change created: https://git.eclipse.org/r/137262
Comment 26 Lars Vogel CLA 2019-02-20 05:13:54 EST
(In reply to Christian Pontesegger from comment #22)
> I do understand your use case, but - to be honest - I do not understand what
> you ask for.
> 
> How do you indicate in the fragment model data whether you want to save it
> or not?

Sorry for the long delay. I made a proposal via Gerrit, please have a look.
Comment 27 Dani Megert CLA 2019-02-20 05:41:36 EST Comment hidden (obsolete)
Comment 28 Eclipse Genie CLA 2019-02-20 11:14:12 EST
New Gerrit change created: https://git.eclipse.org/r/137303
Comment 31 Lars Vogel CLA 2019-02-20 11:37:40 EST
Change to persistedState for M3, Christian or Brian please reopen if you see any issue with that.
Comment 32 Christian Pontesegger CLA 2019-02-21 16:29:53 EST
Looks good to me.
Comment 33 Lars Vogel CLA 2019-02-27 06:19:47 EST
(In reply to Christian Pontesegger from comment #32)
> Looks good to me.

Unfortunately the e4 editor for the Application model and fragments also uses the same persistence mechanism to save the editor, so any model element flagged as non-persistent will be removed during save. 

Workaround is to use a text editor to set the flag. Opened Bug 544871 for the editor.
Comment 35 Dani Megert CLA 2019-03-22 13:35:08 EDT
(In reply to Eclipse Genie from comment #34)
> Gerrit change https://git.eclipse.org/r/137260 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=88c9e51ee1615122c36d4a2fcff345793fc5712b
> 
It's not a good practice to attach a fix to an old resolved bug. Please open a new bug for 4.12, so that it can be tracked properly.