Problem when loading the change files
Closed this issue · 5 comments
Hi again. We want to convert the provided change files to our own change representation. To do this, we need to load the change files programmatically. However, when loading them, we get a weird exception:
Exception in thread "main"
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException:
org.eclipse.emf.ecore.xmi.ClassNotFoundException: Class 'EStructuralFeature' is not found or is abstract. (file:///C:/forschung/ttc/ws_smartgrid/Changes2Deltas/models/COSEM-delta001.xmi, 3, 206)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
The error message does not make immediate sense to us, because the XMI representation of the change never mentions the EStructuralFeature class. The error is also hard to debug since it's not easy to get into the details of the XMI parsing process.
So, we wonder if this is a known issue and if a fix exists.
I have a very bad feeling about this.
I have seen that in EMF, cross-references sometimes have not only the URI of an element, but also the type of the referenced element, in case it is not the same as the type of the reference. In the change representation, the feature of an elementary change is typed as a EStructuralFeature, but of course, the affected features are attributes or references. Maybe EMF assumes the default reference type, although I cannot imagine why it needs it at all, because the type information is not required in that case. Sadly, the serialization of EMF is not really documented, because the handling of cross-references through URIs is not specified in the XMI standard - it rather is some propriatary implementation that NMF tries to mimic as good as it can.
I will try to come up with a solution for this later today.
I will try to come up with a solution for this later today.
This would be terrific. Thanks for your help!
The latest commit c074298 should solve the problem. However, because I manually fixed the generated output (well, I ran some regex find and replace), the change sequences currently ought not be regenerated, as the changes are lost, otherwise.
Great, thanks! Loading the changes now works for me.
We noticed (and apparently, fixed) another smallish issue with the XMI format. In the following line, the element referenced in the highlighted part could not be resolved. This was due to a missing @ before the "addedElement" within the value.
<changes xsi:type="changes:AssociationListInsertion" addedElement="#//@changes.3/addedElement" index="1" affectedElement="CIM_DCIM-out000.xmi#_50321322Loc" feature="ecore:EReference http://iec.ch/TC57/2009/CIM-schema-cim14#//IEC61968/Common/Location/Assets" />
Locally, we fixed this issue by replacing
/addedElement"
with
/@addedElement"
(For some reason, GitHub prints a lower-case "addedelement" in the latter string, but it must be "addedElement", of course.)