Description marc.schlienger 2010-05-19 05:23:20 EDT

Build Identifier: org.eclipse.xtend_0.7.2.v200908120436

When you run various workflows within the same JVM at different point in time, but within the same application context, the checks (model validation) will not be applied if the metamodel they rely on has been configured more than once. Let me explain this with pseudo-code:

given:
transformER2Ecore() calls workflow_1
generateCodeInternal() calls workflow_2

generate() calls transformER2Ecore() and then generateCodeInternal()

NB: the separation in two workflows makes sense, I can explain why if required.

workflow_1:
<bean id="mm" class="org.eclipse.xtend.typesystem.emf.EmfMetaModel">
   <metaModelFile value="my/package/mm.ecore"/>
</bean>
<component class="">
  <metaModel idRef="mm" />
   ... do some transformation
</component>
<component class="org.eclipse.emf.mwe.utils.Writer">
   <uri value="my_file"/>
   <modelSlot value="model" />
</component>

workflow_2:
<bean id="mm" class="org.eclipse.xtend.typesystem.emf.EmfMetaModel">
   <metaModelFile value="my/package/mm.ecore"/>
</bean>
<component class="org.eclipse.emf.mwe.utils.Reader">
   <uri value="my_file"/>
   <modelSlot value="model" />
</component>
<component class="org.eclipse.xtend.check.CheckComponent">
   <metaModel idRef="mm"/>
   <checkFile value="my_check_file"/>
   <emfAllChildrenSlot value="model" />
</component>
...


The checks in the second workflow won't be applied, never! This is due to the fact that the EMF metamodel is instanciated twice, but Check.validate() on line 149 "if (typeToCheck.isInstance(o))" will lead to the call of EClassifierImpl.dynamicIsInstance() when working with dynamic Ecore, which looks like this:

  protected boolean dynamicIsInstance(EObject eObject)
  {
    return eObject.eClass() == this;
  }

As you can see, == is used, but two different instances of the same metamodel are actually compared. Hence, it will eventually return false and the checks won't be applied.

We could implement a workaround (see attachment) by using a patched version of org.eclipse.xtend.typesystem.emf.EmfMetaModel which always takes the metamodel from the EPackage registry if there is one applicable for the given Namespace URI.

We then simply use this metamodel in the workflow and it works for us (see the "2" in the class name of the EmfMetaModel):

workflow_2:
<bean id="mm" class="org.eclipse.xtend.typesystem.emf.EmfMetaModel2">
   <metaModelFile value="my/package/mm.ecore"/>
</bean>


A better solution would be to adjust the behaviour in EcoreUtil2.getEPackage() and registerEPackage(): if an epackage is already registered in EPackage.Registry, the method should always return the one found in the registry instead of the current one just registered (of course, the first time an epackage is registered, it is the same).


Reproducible: Always

Steps to Reproduce:
(see description above)
1. use two or more separate workflow in the same JVM
2. having same metmodels configured more than once
3. the checks of one of the following workflows will not be applied