Strange constraint evaluation failure

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 583086 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Mar 27, 2024 04:05 EDT |
| Modified | May 22, 2024 04:15 EDT |
| See also | 583043 |
| Reporter | Ed Willink |

Description

Bug 583043#c20 describesa repro in which constraint evaluation fails for no evident reason and no adequate diagnostic.

[eclipse-ocl-bot]

By Ed Willink on Mar 27, 2024 05:17

Diagnostic ERROR source=org.eclipse.emf.ecore code=0 The 'Greeting::nameIsValidIdentifier' constraint result is invalid for 'Model::Greeting'

• Failed to evaluate 'myDsl::Greeting::name' for 'org.xtext.example.mydsl.myDsl.impl.GreetingImpl@2009523b (name: Name)' and 'self.name' data=[org.xtext.example.mydsl.myDsl.impl.GreetingImpl@2009523b (name: Name)]

hides

java.lang.IllegalArgumentException: The feature 'name' is not a valid feature

from

Thread [Worker-18: Validity View Validation] (Suspended (exception IllegalArgumentException))
GreetingImpl(BasicEObjectImpl).eOpenGet(EStructuralFeature, boolean) line: 1101
GreetingImpl(BasicEObjectImpl).eGet(EStructuralFeature, boolean, boolean) line: 1054
GreetingImpl(BasicEObjectImpl).eGet(EStructuralFeature, boolean) line: 1042
ExplicitNavigationProperty.evaluate(Executor, TypeId, Object) line: 77
BasicOCLExecutor(AbstractExecutor).internalExecuteNavigationCallExp(NavigationCallExp, Property, Object) line: 393
BasicEvaluationVisitor.visitPropertyCallExp(PropertyCallExp) line: 788
PropertyCallExpImpl.accept(Visitor) line: 445
BasicEvaluationVisitor.evaluate(OCLExpression) line: 146
BasicOCLExecutor(AbstractExecutor).evaluate(OCLExpression) line: 215
ConstrainedOperation.dispatch(Executor, OperationCallExp, Object) line: 79
BasicEvaluationVisitor.visitOperationCallExp(OperationCallExp) line: 736
OperationCallExpImpl.accept(Visitor) line: 572
PivotEObjectValidator$1(AbstractConstraintEvaluator).evaluate(EvaluationVisitor) line: 86
PivotEObjectValidator.validate(EnvironmentFactoryInternal, Constraint, Object, Map<Object,Object>) line: 333
PivotEObjectValidator.validate(Constraint, Object, Map<Object,Object>) line: 356
CompleteOCLCSUIConstraintLocator(CompleteOCLCSConstraintLocator).validate(Result, ValidityManager, Monitor) line: 131
IDEValidityManager(ValidityManager).runValidation(Set, IProgressMonitor) line: 582
IDEValidityManager$ValidityViewJob.run(IProgressMonitor) line: 94
Worker.run() line: 63

But GreetingImpl has a name field.

aargh! It's metamodel schizophrenia again.

[eclipse-ocl-bot]

By Ed Willink on Mar 27, 2024 07:53

(In reply to Ed Willink from comment #1)

aargh! It's metamodel schizophrenia again.

test.ocl imports 'platform:/plugin/org.xtext.example.mydsl/model/generated/MyDsl.ecore'
but MyDsl.xtext generates "http://www.xtext.org/example/mydsl/MyDsl"

with any normal EMF-based tool this would be idiot user, however the OCL tooling has a PlatformMap that is supposed to solve metamodel schizophrenia.

(Changing the test.ocl import to http://www.xtext.org/example/mydsl/MyDsl and the strange validation error goes away.)

Issues:

1. why is the strange error diagnostic so lacking?

2. why didn't metamodel schizophrenia get resolved?

[eclipse-ocl-bot]

By Ed Willink on Mar 27, 2024 08:53

(In reply to Ed Willink from comment #2)

2. why didn't metamodel schizophrenia get resolved?

The MyDSL Xtext editor is running. OCL has not been activated.

The OCL->Load Document action invokes the ResourceDialog constructor where the absence of prior OCL functionality creates a default that prefers the first reference. Unaware that http://www.xtext.org/example/mydsl/MyDsl was accessed by the Xtext editor, the platform:/plugin/org.xtext.example.mydsl/model/generated/MyDsl.ecore import is treated as the first reference.

Xtext's SynchronizedXtextResourceSet is passed to the ResourceDialog constructor so it should be possible for the OCL activation to detect and so prefer the models already loaded by Xtext.

[eclipse-ocl-bot]

By Ed Willink on Mar 28, 2024 03:48

(In reply to Ed Willink from comment #3)

Xtext's SynchronizedXtextResourceSet is passed to the ResourceDialog
constructor so it should be possible for the OCL activation to detect and so
prefer the models already loaded by Xtext.

The StandaloneProjectMap was designed to prepare a standalone application to be metamodel schizophrenia-proof. As such the ResourceSet was expected to be empty so that every EPackage load would be mediated. The ProjectMap extension for OSGI usage has the same expectation, that is not so sound. Changing the standard functionality to assume that whatever is already in the ResourceSet is what the user wants will cost nothing for an empty ResourceSet and may be very beneficial for a pre-existing active ResourceSet.

[eclipse-ocl-bot]

By Ed Willink on May 22, 2024 04:15

(In reply to Ed Willink from comment #4)

Changing the standard functionality to assume that whatever is already in
the ResourceSet is what the user wants

doesn't solve the problem. (The code weas already commented to suggest this enhancement.)

The OCL parser that runs on a worker thread uses the worker thread's EnvironmentFactory rather than the EnvironmentFactory passed from the main part-thread. The required attachEnvironmentFactory to configure the workder thread is present but commented out; clearly a false optimization for which no test demonstrates the necessity.