Bug 577462

Summary: Opening a part descriptor with persistState=false should also set the persistState=false on the reference
Product: [Eclipse Project] Platform Reporter: Lars Vogel <Lars.Vogel>
Component: UIAssignee: Platform-UI-Inbox <Platform-UI-Inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: Ed.Merks, Lars.Vogel, loskutov, rolf.theunissen
Version: 4.21   
Target Milestone: ---   
Hardware: PC   
OS: All   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577275
Whiteboard:
Bug Depends on:    
Bug Blocks: 578743    

Description Lars Vogel CLA 2021-11-25 05:02:07 EST 
In Bug 577275 we see that opening a part with persistState=false, damanges the persisted workbench.xmi so that the original state of the workbench is restored.

One solution would be copy the pesisted state to the reference so that both elements gets removed during save of the workbench.xml.

Maybe if we go for this approach, most likely we should copy the whole persisted state over.
Comment 1 Lars Vogel CLA 2021-11-25 05:15:39 EST 
Rolf, WDYT?
Comment 2 Rolf Theunissen CLA 2021-11-25 08:06:30 EST 
If I remember correctly, when a placeholder is created the tags of a part are copied to the placeholder. Something similar could be done for the persisted state. Though this results in some kind of tri-state, should the state of a placeholder override the state of a part? This would surely increase complexity.

We could have a discussion if the persisted state flag should have been added as a tag, but in the end that doesn't really matter.

In general, and that is the root cause of the bug, when some element is not persisted all references to that element should also not be persisted, otherwise there will be dangling references when loading the file again, i.e. there is a UnresolvedReferenceException. This is true for all references in the model.

To solve the general reference case, E4XMISave should override the saveElementReference method to filter out references to elements that are not persisted. This can result in 'null' references when the model is loaded again, which might result in a different set of problems, e.g. a placeholder that is not referencing any part. But it will not throw errors while loading the xmi resource.
Comment 3 Rolf Theunissen CLA 2022-02-15 08:58:56 EST 
@Ed Do you have an idea: in the E4 persistence some elements are not serialized, however there reference to this element is still serialized. This results in UnresolvedReferenceException when the resource is loaded again.

I was looking at the code, but it seems that there are many places where references are serialized. Do you think this is fixable in the persistence layer, or should we remove the elements from the model before persisting it (which requires making deep clones to not mess with the running UI instance).
Comment 4 Ed Merks CLA 2022-02-15 10:13:32 EST 
I see you have E4XMISave.saveElement(InternalEObject, EStructuralFeature).  I suspect that maybe the same guards for the following method will avoid saving references to objects that are not serialized as contained objects:

@Override
protected void saveElementReference(EObject remote, EStructuralFeature f) {
	super.saveElementReference(remote, f);
}

It's worth a try...