Home » Modeling » EMF » OCL typecheck in dynamic instance(Using oclIsKindOf() to check the type of a dynamic EObject to be a type defined in a different package doesn't work)
| OCL typecheck in dynamic instance [message #691174] |
Thu, 30 June 2011 21:41  |
 Tim Schaefer
Messages: 49
Registered: June 2011
Location: Marburg, Germany |
Member |
|
|
Hi,
I have two ecore meta-models: a.ecore and b.ecore
a.ecore has two EClasses, A1 and A2 -> A1, i.e. A2 extends A1.
Similarily, b.ecore has two EClasses B1 and B2 -> B1.
Class B1 has an EReference (1:1, named "ref") of type A1 (from package "a").
Now, although the type of "ref" is A1, I want an instance of B2 to reference an instance of type A2 (and not of its superclass).
For this purpose I added an OCL constraint on B2 (in my use-case I can not change the type of the EReference):
This works fine when generated code is used.
However, creating a (valid) dynamic instance of a.ecore and b.ecore, validation of this constraint fails.
Curiously, the first time the instance of b.ecore is opened (with Reflective Ecore Editor), validation succeeds. After re-opening the resource (no matter how many times) it fails.
With the help of the debugger I figured out that evaluation of oclIsKindOf() ultimately leads to invocation of EClass.isSuperTypeOf(EClass anotherClass).
The method is defined as:
public boolean isSuperTypeOf(EClass someClass)
{
return someClass == this || someClass.getEAllSuperTypes().contains(this);
}
and returns false because the two EClass instances are equal, but not identical.
Note that the dynamic instances of a.ecore and b.ecore are opened in the same ResourceSet.
Does this have something to do with registering dynamic packages?
I heard of a "dynamic_package" extension point that can be set for a plug-in, but since I use dynamic EMF there is no plug-in where I could do this.
Any ideas? 
|
|
|
| Re: OCL typecheck in dynamic instance [message #691258 is a reply to message #691174] |
Fri, 01 July 2011 05:59  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Tim
Thanks for the detail; though models would be helpful. I eventually
managed to reproduce this.
From 'ultimately leads to invocation of EClass.isSuperTypeOf(EClass
anotherClass)' I deduce that you are using the Helios release.
'Curiously, the first time the instance of b.ecore is opened (with
Reflective Ecore Editor), validation succeeds. After re-opening the
resource (no matter how many times) it fails.'
This sounds remarkably like meta-model schizophrenia; two different
versions of the same meta-model; typically one from genmodel and another
from *.ecore. In this case something evil has happened. The OCL
constraint was evaluated and so parsed and cached by one editor, and
then the cached value was used by another. Each editor has its own
ResourceSet and so its own set of classes and so the two classes are not
equal as you observed.
For the Helios release, the OCL and EMF developers can decide whether
EMF should have used a ResourceSet-specific delegate registry rather
than the Global one, or whether OCL should refrain from caching ASTs
with type references. https://bugs.eclipse.org/bugs/show_bug.cgi?id=350893.
This problem has gone away for the Indigo release in which types are
resolved via an internal pivot model where meta-model schizophrenia can
be controlled. Unfortunately your example breaks the new parser since
there is no import statement to clarify the external package path.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350894.
I'm not sure that that helps you very much. For now, I can only suggest
that if you need to invoke the Reflective Ecore Editor repeatedly, then
you write a little program that wipes the global validation registry and
invoke it between invocations.
Regards
Ed Willink
On 30/06/2011 23:41, Tim ch wrote:
> Hi,
>
> I have two ecore meta-models: a.ecore and b.ecore
> a.ecore has two EClasses, A1 and A2 -> A1, i.e. A2 extends A1.
> Similarily, b.ecore has two EClasses B1 and B2 -> B1.
> Class B1 has an EReference (1:1, named "ref") of type A1 (from package
> "a").
>
> Now, although the type of "ref" is A1, I want an instance of B2 to
> reference an instance of type A2 (and not of its superclass).
> For this purpose I added an OCL constraint on B2 (in my use-case I can
> not change the type of the EReference):
> ref.oclIsKindOf(a::A2)
> This works fine when generated code is used.
> However, creating a (valid) dynamic instance of a.ecore and b.ecore,
> validation of this constraint fails.
> Curiously, the first time the instance of b.ecore is opened (with
> Reflective Ecore Editor), validation succeeds. After re-opening the
> resource (no matter how many times) it fails.
>
> With the help of the debugger I figured out that evaluation of
> oclIsKindOf() ultimately leads to invocation of
> EClass.isSuperTypeOf(EClass anotherClass).
> The method is defined as:
> public boolean isSuperTypeOf(EClass someClass)
> {
> return someClass == this ||
> someClass.getEAllSuperTypes().contains(this);
> }
> and returns false because the two EClass instances are equal, but not
> identical.
>
> Note that the dynamic instances of a.ecore and b.ecore are opened in
> the same ResourceSet.
>
> Does this have something to do with registering dynamic packages?
> I heard of a "dynamic_package" extension point that can be set for a
> plug-in, but since I use dynamic EMF there is no plug-in where I could
> do this.
>
> Any ideas? :)
|
|
|
| Re: OCL typecheck in dynamic instance [message #691452 is a reply to message #691258] |
Fri, 01 July 2011 13:40 |
Tim Schaefer
Messages: 49
Registered: June 2011
Location: Marburg, Germany |
Member |
|
|
Hi Edward,
thanks for the reply.
So, this is actually a bug?
If that's the case (and eventually it will be fixed in the future), I can live very
well with it. Personally, I don't need to re-open the editor repeatedly, but people
using the project I'm currently working on might do so. I was just confused about the
odd behavior and thought this resulted of me doing something wrong.
'This problem has gone away for the Indigo release in which types are
resolved via an internal pivot model where meta-model schizophrenia can
be controlled. Unfortunately your example breaks the new parser since
there is no import statement to clarify the external package path.'
I'm not familiar with the Indigo release.
Can you explain, how I can adopt my example so it won't break the new parser?
Regards,
Tim
[Updated on: Fri, 01 July 2011 13:41] Report message to a moderator |
|
| | |
Goto Forum:
Current Time: Thu Apr 25 12:28:12 GMT 2024
Powered by FUDForum. Page generated in 0.03387 seconds |
] 
Search
Help
Register
Login
Home
