Community
Participate
Working Groups
Discovered in the latest Papyrus-RT nightly builds based on Papyrus Neon M6. In Papyrus-RT, the creation of Ports and Capsule-parts in a Capsule Diagram includes a particle of advice in both cases that prompts for selection or creation of dependencies: in the case of ports, a Protocol to type the port and in the case of parts, a Capsule to type the part. In both cases, the RuntimeValuesAdvice is used to launch a dialog to edit the properties of the new object. In both cases, the only property presented in the dialog is the port's or part's type. It isn't material to the bug that this is the only property presented, only that it is one of the properties presented. The reason is that both of these "type" properties are implemented by a ReferenceDialog [sic] widget, which offers to create a new protocol/capsule type as appropriate. The problem is that when completing the creation of a port or part in which the dialog is used to additionally create its type, a subsequent undo only undoes the creation of the type protocol/capsule by this advice. The original core operation that is creation of the port/part doesn't end up on the undo history at all. *However*, this is only a problem when using the palette tool in the diagram to create the new port or part. Doing the same from the context menu in the Model Explorer works correctly in the undo scenario. Debugging the problem, I see that the reason for this is that we have two different command-stacks in play in the diagram scenario, but only one in the Model Explorer scenario. The AspectUnspecifiedTypeCreationTool in the palette uses the DiagramCommandStack to perform the initial command execution. But then the property-sheet widgets instantiated in the EditionDialog [sic] by the RuntimeValuesAdvice use a different stack, the editing domain's EMF CommandStack, to execute the (nested) commands within the dialog. In the ModelExplorer cases, this is fine, because the Papyrus specialization of the EMF CommandStack is used for the initial command execution also, and because it properly supports re-entrant (nested) command execution, it captures all of the required undo context information correctly to surface the topmost command (only) on the Undo history. The problem in the diagram case is that the nested command execution in the dialog doesn't know that it's actually performing re-entrant execution of operations on (ultimately) Eclipse's operation history. So, those commands end up on the history in their own right and the original command doesn't get tagged with the undo contexts required to make it show up in the editor's Undo menu. Steps to reproduce: 1. In a recent Papyrus-RT nightly (you will need the fix pending for bug 491473) use the Port tool to create a new port on a capsule in a Capsule Diagram. 2. In the dialog that pops up, create a new Protocol for the port. 3. Finish the dialog to see the new port appear in the diagram. 4. Hit Undo. See the port's type be cleared to <Undefined>. The port still exists. 5. Observe that you cannot undo again to get rid of the port. That operation is not on the history selected by the editor because it is missing the requisite undo context.
New Gerrit change created: https://git.eclipse.org/r/70509
Per the last comment on the Gerrit change, I have concluded that the RuntimeValuesAdvice is fundamentally incompatible with the diagram infrastructure, so I shall take a different approach to the configuration of the new port or part in a capsule structure diagram.
OMG this is complicated. Now I discover almost immediately on starting down a new path that the exception I was seeing that I thought was related to this whole RuntimeValuesAdvice dialog undo/redo problem isn't at all. It even happens in the absence of this patch and in the absence of the dialog altogether. It is entirely a bug in the core command that creates the port shape in the diagram in the first place.
For completeness, here is the exception that I had thought for so long was related to this bug but is, in fact, completely independent of it and contained within the actual simple creation of a port shape in the capsule structure diagram: !ENTRY org.eclipse.emf.workspace 4 25 2016-04-14 15:13:01.437 !MESSAGE Redo of operation was rolled back (possibly due to concurrent write) !STACK 0 org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: index=0, size=0 at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:346) at org.eclipse.emf.ecore.change.impl.ListChangeImpl.process(ListChangeImpl.java:534) at org.eclipse.emf.ecore.change.impl.ListChangeImpl.applyAndReverse(ListChangeImpl.java:486) at org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.preApply(ChangeDescriptionImpl.java:818) at org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.applyAndReverse(ChangeDescriptionImpl.java:324) at org.eclipse.emf.transaction.util.CompositeChangeDescription.applyAndReverse(CompositeChangeDescription.java:149) at org.eclipse.emf.workspace.AbstractEMFOperation.doRedo(AbstractEMFOperation.java:722) at org.eclipse.emf.workspace.AbstractEMFOperation.redo(AbstractEMFOperation.java:461) at org.eclipse.gmf.runtime.diagram.ui.internal.commands.ToggleCanonicalModeCommand.redo(ToggleCanonicalModeCommand.java:206) at org.eclipse.gmf.runtime.diagram.ui.commands.CommandProxy.doRedoWithResult(CommandProxy.java:58) at org.eclipse.gmf.runtime.common.core.command.AbstractCommand.redo(AbstractCommand.java:175) at org.eclipse.gmf.runtime.common.core.command.CompositeCommand.doRedoWithResult(CompositeCommand.java:514) at org.eclipse.gmf.runtime.common.core.command.AbstractCommand.redo(AbstractCommand.java:175) at org.eclipse.core.commands.operations.DefaultOperationHistory.doRedo(DefaultOperationHistory.java:340) at org.eclipse.core.commands.operations.DefaultOperationHistory.redo(DefaultOperationHistory.java:1014) at org.eclipse.papyrus.infra.emf.gmf.command.CheckedOperationHistory.redo(CheckedOperationHistory.java:275) at org.eclipse.papyrus.infra.emf.gmf.command.NotifyingWorkspaceCommandStack.redo(NotifyingWorkspaceCommandStack.java:335) at org.eclipse.papyrus.infra.emf.gmf.command.NestingNotifyingWorkspaceCommandStack.redo(NestingNotifyingWorkspaceCommandStack.java:225) at org.eclipse.papyrus.views.modelexplorer.handler.RedoHandler.execute(RedoHandler.java:41) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) ...
Gerrit change https://git.eclipse.org/r/70509 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=928852a40e704d8d53906edfe78f27f5e66c6c95
Fixed on the master branch for Neon M7.
