DirtyState Issue / NPE When Refactoring

[philip-alldredge]

Issue by philip-alldredge
Wednesday Aug 09, 2017 at 15:19 GMT
Originally opened as osate/osate-ge#210

---

While testing refactoring, a NPE is received occasionally. Below is a snipped from the stack trace.

However, the cause of this bug implies an even more critical issue. The bug occurs when the user tries to edit a "live" xtext document and the refactoring processor isn't able to retrieve the element via an xtext resource set using the live scope. The reason this occurs is that under some circumstances, the DirtyStateManager may not contain the dirty state of a resource. This results in the version in the file being used.

It is plausible that under some circumstances, the editor would potentially retrieve an incorrect model resource via the URI and refactor it. I am unaware of other cases this may affect. The editor doesn't use live scoped xtext resource sets or the built-in dirty state manager at this time so the damage is relatively limited. However, in the future, the editor should likely use the built-in capability of xtext.

The issue appears to be in xtext.

Steps to reproduce

• Make whitespace change to text editor.
• Save. This results in a markEditorClean/discardDirtyState. State is now should_update.
• Switch to graphical editor and create a subcomponent. This results in a announceDirtyStateChanged() which attempts to replace. Doesn't add element because replace...

Stack Trace

java.lang.NullPointerException
	at org.eclipse.xtext.ui.refactoring.impl.RenameElementProcessor.checkInitialConditions(RenameElementProcessor.java:219)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkInitialConditions(ProcessorBasedRefactoring.java:203)
	at org.osate.ge.internal.graphiti.features.BoHandlerDirectEditFeature.prepareAndCheck(BoHandlerDirectEditFeature.java:231)
	at org.osate.ge.internal.graphiti.features.BoHandlerDirectEditFeature.setValue(BoHandlerDirectEditFeature.java:160)
	at org.eclipse.graphiti.internal.command.DirectEditingFeatureCommandWithContext.execute(DirectEditingFeatureCommandWithContext.java:81)
	at org.eclipse.graphiti.ui.internal.command.GefCommandWrapper.execute(GefCommandWrapper.java:51)
	at org.eclipse.graphiti.ui.internal.editor.EmfOnGefCommand.execute(EmfOnGefCommand.java:54)
	at org.eclipse.graphiti.internal.command.GFPreparableCommand2.doExecute(GFPreparableCommand2.java:43)
	at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
	at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119)
	at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
	at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:516)
	at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)

Steps Ahead

• Reproduce issue in an Xtext unit test.
• Report issue to xtext developers.

[philip-alldredge]

Comment by philip-alldredge
Wednesday Aug 09, 2017 at 16:19 GMT

---

Xtext Issue:
eclipse/xtext-eclipse#326

[philip-alldredge]

Comment by philip-alldredge
Wednesday Aug 09, 2017 at 17:37 GMT

---

A workaround has been added to the direct editing feature. This workaround saves the editor before trying to refactor. Remove the workaround when the issue is resolved.

[philip-alldredge]

Comment by philip-alldredge
Friday Sep 22, 2017 at 16:25 GMT

---

Another work around is being added soon to DefaultAadlModificationService. The workaround will call doVerify() on the editor's dirty state editor support to ensure that the dirty state from the editor is being managed.