Closed eclipse-ocl-bot closed 1 month ago
eclipse-ocl-bot
commented
1 month ago By Adolfo Sanchez-Barbudo Herrera on Feb 24, 2015 07:35
I've created a asanchez/460682 branch in the QVTd repo, exposing the failing "testExample2_Interpreted". Then, I can go on with pushes of asanchez/nameResoCG
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 25, 2015 18:33
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #0)
I let you decide if you want to workaround the issue in OCL code or convince EdM to relax the cast to a Collection rather than a List ;)
Ecore has its required representation classes (ecore)\ Classic OCL has different required representation classes (unboxed)\ Pivot OCL has further required representation classes (boxed)
The representation should always be adjusted to the required API. The Ecore/unboxed separation is recent so maybe there is a missing conversion.
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 27, 2015 02:22
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #0)
hidden exception[1] produced when assigning the ConstructorPart initValue to
...
which produces the exception is org.eclipse.emf.ecore.util.EcoreEList (line 457):
...
[1] java.util.LinkedHashSet cannot be cast to java.util.List
Your analysis may be helpful but when it replaces the stack trace it just makes my life hard.
Thread [main] (Suspended (exception ClassCastException)) \
EcoreEList$Dynamic
....\
MappingImpl.accept(Visitor
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 27, 2015 02:39
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #0)
fails without apparent clue about the problem
There is actually:
visitPropertyAssignment InvalidValueException: Failed to evaluate env::Environment::addElements(Collection(classes::NamedElement)) : env::Environment
resulting from
} catch (InvalidValueException ex) {\ // There was an OCLVoid value being navigated or any other/similar OCL error\ // evaluating the slot or value expression\ // TODO, is this an error?\ System.out.println("visitPropertyAssignment InvalidValueException: " + ex.getMessage());\ }
in doPropertyAssignment().
We now have a policy that anything bad is bad, so the exception should propagate. Once changed, the JUnit test verdict shows the stack trace with the CCE.
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 27, 2015 03:09
(In reply to Ed Willink from comment #4)
There is actually:
Ah! That was your debug code.
(In reply to Ed Willink from comment #2)
The representation should always be adjusted to the required API.
PropertyImpl.initValue is commented as "ecoreValue" but asserts "unboxedValue".
Changing the ConstructorExp conversion to ecoreValueOf and correcting the assertion and the bug is fixed.
OCL: commit 4d71457710500965668633c10598229500d8907d
QVTd: commit aa8d6799d406fc3c75b0c618a67bdab8cfb719a7
pushed to master for M6.
| --- | --- | | Bugzilla Link | 460682 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Feb 24, 2015 07:26 EDT | | Modified | Feb 27, 2015 03:09 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |
Description
In the OCL2QVTi test cases suite I'm working on (asanchez/nameResoCG in QVTd repo), I've detected a deficiency in the OCL Pivot evaluator. In this case related to initializing multi-valued properties (in a ConstructorPart) using collections other than Sequence as the initializing value. E.g:
In the examples2 package of the test suite, ClassesLookup.ocl file, there is an expression like the following:
def : addElements(elements : Collection(classes::NamedElement)) : Environment =\ Environment{\ namedElements = namedElements->includingAll(elements)\ }
The execution of the test case "testExample2_Interpreted" fails without apparent clue about the problem. After some deep debugging, there is a hidden exception[1] produced when assigning the ConstructorPart initValue to the corresponding Environment::namedElements reference. The line of code which produces the exception is org.eclipse.emf.ecore.util.EcoreEList (line 457):
@SuppressWarnings("unchecked")\ public void set(Object newValue)\ {\ clear();\ addAll((List<? extends E>)newValue);\ }
As a workaround I'm including some asSequence() conversions in order to avoid the exception and make the constructorPart initialization take place:
def : addElements(elements : Collection(classes::NamedElement)) : Environment =\ Environment{\ namedElements = namedElements->asSequence()->includingAll(elements)\ }
I let you decide if you want to workaround the issue in OCL code or convince EdM to relax the cast to a Collection rather than a List ;)
[1] java.util.LinkedHashSet cannot be cast to java.util.List