Community
Participate
Working Groups
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.
Rolf, WDYT?
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.
@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).
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...
