Democles seems to be trying to access invalid features

[anthonyanjorin]

Hi Greg,

I'm getting a strange assertion exception from EMF when running the pattern matcher for an example with Ecore (I'm searching for a pattern in a metamodel).

In the pattern there's an attribute condition containment == false for an EReference. In the debugger, I can see that Democles seems to be trying to get the value of the feature containment for an EOperation, which obviously fails as EOperation does not have this feature. I have no idea why and how this is happening.

The exception trace is below.

To try out the example you can import this PSF

You just need to run the project BenchmarxEcoreToSQL as a JUnit Test suite. You should then see the test results for [IBeX] and the assertion exception. While you can debug the code note that it is included as a jar so I'm not exactly sure how you can swap Democles (perhaps just include it earlier in the class path?). If you want to try out a fix I can of course help to set up a more standard workspace without a jar.

java.lang.AssertionError: The feature 'containment' is not a valid feature
    at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDerivedStructuralFeatureID(BasicEObjectImpl.java:1504)
    at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
    at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
    at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:998)
    at org.gervarro.democles.operation.emf.UnidirectionalToOneOperation.getDataFrame(UnidirectionalToOneOperation.java:49)
    at org.gervarro.democles.runtime.DelegatingAdornedOperation.getDataFrame(DelegatingAdornedOperation.java:39)
    at org.gervarro.democles.runtime.RetroactiveBatchDeletionSimulator.getDataFrame(RetroactiveBatchDeletionSimulator.java:42)
    at org.gervarro.democles.runtime.HistoryBasedInterpretableOperation.getDataFrame(HistoryBasedInterpretableOperation.java:45)
    at org.gervarro.democles.runtime.QueryableRemappingOperation.getDataFrameProvider(QueryableRemappingOperation.java:57)
    at org.gervarro.democles.runtime.InternalBidirectionalOperation.lookupInternalDataFrameProvider(InternalBidirectionalOperation.java:40)
    at org.gervarro.democles.runtime.InternalBidirectionalOperation.lookupInternalDataFrameProvider(InternalBidirectionalOperation.java:1)
    at org.gervarro.democles.runtime.JoinOperation.execute(JoinOperation.java:37)
    at org.gervarro.democles.runtime.EventHandlingTask.perform(EventHandlingTask.java:37)
    at org.gervarro.democles.common.runtime.Session.run(Session.java:34)
    at org.gervarro.democles.runtime.IncrementalUpdateSession.call(IncrementalUpdateSession.java:143)
    at org.gervarro.democles.interpreter.incremental.rete.RetePatternMatcherModule.performIncrementalUpdates(RetePatternMatcherModule.java:115)
    at org.emoflon.ibex.gt.democles.runtime.DemoclesGTEngine.updateMatches(DemoclesGTEngine.java:319)
...

[gervarro]

Hi Tony,

how can I have an older version (Java 8) of IBeX to avoid the installation of Java 10, Eclipse Photon, new dev workspace for Democles etc. just to check and fix this case?

Bests, Greg

[anthonyanjorin]

Hi Greg,

I don’t think you need the ibex dev workspace:

1. You could check out the example project and debug (it’s a benchmark example so includes a fat jar with everything it needs).
2. To debug changes in Democles, you could install ibex, but check out Democles and then start a runtime Eclipse workspace.

Would one of these options be ok? Java 8 should certainly work, I’m not sure about Eclipse <= Photon, though. I would have to try that out.

Cheers and thanks, Tony

[gervarro]

Hi Tony,

the problem is that the fat jar file contains code (e.g., org.emoflon.ibex.tgg.run.ibextggecoretosql.SYNC_App) that has been compiled for Java 10 (version 54). I get a java.lang.UnsupportedVersionError when running the tests.

Bests, Greg

[anthonyanjorin]

Ahhh... then I can fix this right away.

[anthonyanjorin]

Ok it should work now.

[gervarro]

Hi Tony,

let us start with the testCreateSimpleCompositeList test case. Please check the ecore.ETypedElement_ecore.ETypedElement.eType_ecore.EClassifier_containment_EQUAL_false/upperBound_EQUAL_-1/____EDGE/2 pattern. In the runtime representation of this pattern, I found the following operation BidirectionalJoinOperation@1(http://www.eclipse.org/emf/2002/Ecore#//EReference/containment^BF->[0,2],http://www.eclipse.org/emf/2002/Ecore#//ETypedElement^U->[0]). This means that you aim to perform a containment attribute lookup on an object of type ETypedElement, which is not necessarily an EReference (e.g., EAttribute is a good counterexample that actually fails with the assertion error). I guess that the variable source on which you look up the containment attribute should be of type EReference in the pattern specification instead of ETypedElement. The EOperation based errors might be the same or something very similar as EOperation is also a subclass of ETypedElement.

Bests, Greg

[anthonyanjorin]

Ahh... these are auto-generated patterns so can be wrongly typed (if the pattern generator is buggy). I don't think it is possible to specify such patterns in the editor.

We plan to rework these generated patterns very soon anyway so hopefully this problem will go away.

Thanks! Tony