[pivot] EMF/OCL Validation concurrency conflict

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 583176 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 16, 2024 13:47 EDT | | Modified | May 28, 2024 03:34 EDT | | Reporter | Ed Willink |

Description

The stack trace below can happen when activating Live Validation for XMITestFile.xmi from the validation tutorial.

Problem is that the ResourceSet is not synchronized between the Validation Job thread transiently installing a *.essentialocl Resource and the main thread updating the problem indications.

a) The lack of synchronization is an EMF bug, but EMF is not threadsafe and the need for the Live Validation application to support thread safety has never been designed in.

b) mutation of a ResourceSet by a 'read-only' Validation Job is a poor OCL practice.

OCL could therefore avoid provoking the EMF bug.

org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: index=2, size=2\ at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:345)\ at org.eclipse.emf.edit.ui.util.EditUIMarkerHelper.hasMarkers(EditUIMarkerHelper.java:157)\ at org.eclipse.emf.common.ui.MarkerHelper.hasMarkers(MarkerHelper.java:194)\ at org.eclipse.emf.ecore.presentation.EcoreEditor.updateProblemIndication(EcoreEditor.java:790)\ at org.eclipse.emf.ecore.presentation.EcoreEditor$2$1.run(EcoreEditor.java:486)\ at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)\ at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)\ at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4047)\ at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3663)\ at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1151)\ at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)\ at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1042)\ at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:152)\ at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:639)\ at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)\ at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:546)\ at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)\ at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)\ at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:208)\ at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:143)\ at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:109)\ at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:439)\ at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:271)\ at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\ at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)\ at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\ at java.base/java.lang.reflect.Method.invoke(Method.java:568)\ at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:651)\ at org.eclipse.equinox.launcher.Main.basicRun(Main.java:588)\ at org.eclipse.equinox.launcher.Main.run(Main.java:1459)\ at org.eclipse.equinox.launcher.Main.main(Main.java:1432)

[eclipse-ocl-bot]

By Ed Willink on Apr 16, 2024 13:57

(In reply to Ed Willink from comment #0)

OCL could therefore avoid provoking the EMF bug.

The need for a distinct .essentialocl Resource for each EAnnotation OCL snippet is unpleasant since it involves multiple parser activations. However creating a composite (? .oclinecore / *.ocl ?) for an amalgamated parse is extra work and prevents lazy analysis.

Perhaps each *.essentialocl could be placed in an 'extra' external ResourceSet so that the EMF editor doesn't see them in the AdapterFactoryEditingDomain$AdapterFactoryEditingDomainResourceSet (and so that they are bulk cleared when done).

(Even if a composite *.ocl was synthesized, it would be naughty to put it in the AdapterFactoryEditingDomain$AdapterFactoryEditingDomainResourceSet and confusing to show problems wrt both EAnnotations and ExpressionInOCLs.)

[eclipse-ocl-bot]

By Ed Willink on May 19, 2024 05:09

(In reply to Ed Willink from comment #1)

Perhaps each *.essentialocl could be placed in an 'extra' external ResourceSet so that the EMF editor doesn't see them

This is easy and seems to have no ripples. Single call to AbstractEnvironmentFactory.getExtraResourceSet() comes from AbstractParserContext.createBaseResource() from AbstractParserContext.parse for an ExpressionInOCL which is precisely the problem use case.

---

Except that the validation tutorial fails after loading a Complete OCL document

A similar problem occurs when repeatedly activating Live Validation for XMITestFile.xmi from the validation tutorial.

[eclipse-ocl-bot]

By Ed Willink on May 28, 2024 03:34

This is probably the result of the misguided attempt to re-use a traditional EMF ResourceSet as the OCL external ResourceSet, which allows OCL activities to interact badly with EMF activities.

If we revert to an OCL-private external ResourceSet there is no problem cluttering it with *.essewntial OCL. We can use a resourceLocator to allow getResource to 'see' the EMF externals in the OCL externals without conflict.

There should be no need for an extraResourceSet.