Home » Modeling » EMF » Problem with different instances of the same EClass
|
| Re: Problem with different instances of the same EClass [message #647107 is a reply to message #647085] |
Tue, 04 January 2011 16:01   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Chris,
Comments below.
Chris wrote:
> Hi everybody,
>
> I have a strange problem: Sometimes, checks like
> eClassA.isSuperType(eClassB) fail unexpectedly. Debugging revealed that
> the supertypes of eClassB indeed contain an instance of EClassA;
> however, it's a different instance than eClassA. Since isSuperType()
> relies on comparison of the object references (i.e., it will be checked
> whether eClass1 == eClass2), the method "fails".
>
> My Problem is that I have no idea why there would be different instances
> of the same EClass hanging around in my system. All involved metamodels
> seem to be registered fine... Has anybody seen something like this
> before, or has any idea why that happens?
>
Have you checked eClassA.getEPackage().eResource().getURI(). If it's a
loaded package the containing resource's URI will tell you where it's
loaded from. You might set a conditional breakpoint in
EPackageImpl.setNsURI, checking for the nsURI of the package you know is
being loaded, to see what's causing it to be loaded.
> Thanks in advance,
> Chris
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with different instances of the same EClass [message #647420 is a reply to message #647107] |
Thu, 06 January 2011 08:24 |
chris
Messages: 72
Registered: July 2009 |
Member |
|
|
Dear Ed,
thanks for your fast and helpful reply...
Am 04.01.2011 17:01, schrieb Ed Merks:
>> I have a strange problem: Sometimes, checks like
>> eClassA.isSuperType(eClassB) fail unexpectedly. Debugging revealed that
>> the supertypes of eClassB indeed contain an instance of EClassA;
>> however, it's a different instance than eClassA. Since isSuperType()
>> relies on comparison of the object references (i.e., it will be checked
>> whether eClass1 == eClass2), the method "fails".
>>
>> My Problem is that I have no idea why there would be different instances
>> of the same EClass hanging around in my system. All involved metamodels
>> seem to be registered fine... Has anybody seen something like this
>> before, or has any idea why that happens?
>>
> Have you checked eClassA.getEPackage().eResource().getURI(). If it's a
> loaded package the containing resource's URI will tell you where it's
> loaded from. You might set a conditional breakpoint in
> EPackageImpl.setNsURI, checking for the nsURI of the package you know is
> being loaded, to see what's causing it to be loaded.
If I get you right, then EPackageImpl.setNsUri should only be called
when the init method of my metamodel's package class is called. This was
quite helpful - it turned out that the package is indeed loaded again.
However, I'm not sure why this happens.
The problem occurs when calling EClass.getEAllSupertypes. The class I'm
calling on seems to be fine according to this code:
EPackage ePackage =
EPackage.Registry.INSTANCE.getEPackage(eclass.getEPackage(). getNsURI());
EClassifier registeredClassifier =
ePackage.getEClassifier(eclass.getName());
Afterwards, registeredClassifier == eclass. However, the package is
loaded again during getEAllSuperTypes - the resulting EClasses indeed
contain one class such that the above check fails.
I have also checked the resources_ uris on the failing EClasses: one URI
is the metamodel's nsUri (as probably desired), and the other one is a
platform URI pointing to that metamodel. Now, I noticed that the
according references in the ecore metamodel either look like
<eClassifiers xsi:type="ecore:EClass" xmi:id="_Q0PN8BixEeClyuEUzwXIhg"
name="EClassB"
eSuperTypes=" platform:/plugin/my.plugin.id/model/MyMetamodel.ecore#//ECla ssA "/>
or
<eClassifiers xsi:type="ecore:EClass" xmi:id="_Q0PN8BixEeClyuEUzwXIhg"
name="EClassB"
eSuperTypes="../../my.plugin.id/model/MyMetamodel.ecore#//EClassA "/>
(depending on whether I loaded the referenced metamodel within the Ecore
editor through "Browse registered packages" or "Browse workspace"). I
would have expected the actual nsUri of the referenced metamodel here -
could this be the problem? (I tried to "repair" the according references
textually, but I can't reload the related genmodel any more).
Thanks in advance for your help,
Chris
--
Paul Valery: "The trouble with our times is that the future is not what
it used to be."
|
|
|
| Re: Problem with different instances of the same EClass [message #647496 is a reply to message #647420] |
Thu, 06 January 2011 16:44 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080607030407040108020102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Chris,
Comments below.
Chris wrote:
> Dear Ed,
>
> thanks for your fast and helpful reply...
>
> Am 04.01.2011 17:01, schrieb Ed Merks:
>
>>> I have a strange problem: Sometimes, checks like
>>> eClassA.isSuperType(eClassB) fail unexpectedly. Debugging revealed that
>>> the supertypes of eClassB indeed contain an instance of EClassA;
>>> however, it's a different instance than eClassA. Since isSuperType()
>>> relies on comparison of the object references (i.e., it will be checked
>>> whether eClass1 == eClass2), the method "fails".
>>>
>>> My Problem is that I have no idea why there would be different instances
>>> of the same EClass hanging around in my system. All involved metamodels
>>> seem to be registered fine... Has anybody seen something like this
>>> before, or has any idea why that happens?
>>>
>>>
>> Have you checked eClassA.getEPackage().eResource().getURI(). If it's a
>> loaded package the containing resource's URI will tell you where it's
>> loaded from. You might set a conditional breakpoint in
>> EPackageImpl.setNsURI, checking for the nsURI of the package you know is
>> being loaded, to see what's causing it to be loaded.
>>
>
> If I get you right, then EPackageImpl.setNsUri should only be called
> when the init method of my metamodel's package class is called.
It could also happen when you deserialize one
> This was
> quite helpful - it turned out that the package is indeed loaded again.
> However, I'm not sure why this happens.
>
The stack should help answer that.
> The problem occurs when calling EClass.getEAllSupertypes. The class I'm
> calling on seems to be fine according to this code:
>
> EPackage ePackage =
> EPackage.Registry.INSTANCE.getEPackage(eclass.getEPackage(). getNsURI());
> EClassifier registeredClassifier =
> ePackage.getEClassifier(eclass.getName());
>
> Afterwards, registeredClassifier == eclass. However, the package is
> loaded again during getEAllSuperTypes - the resulting EClasses indeed
> contain one class such that the above check fails.
>
So some other model is referencing a different version of it.
> I have also checked the resources_ uris on the failing EClasses: one URI
> is the metamodel's nsUri (as probably desired), and the other one is a
> platform URI pointing to that metamodel. Now, I noticed that the
> according references in the ecore metamodel either look like
>
> <eClassifiers xsi:type="ecore:EClass" xmi:id="_Q0PN8BixEeClyuEUzwXIhg"
> name="EClassB"
>
> eSuperTypes=" platform:/plugin/my.plugin.id/model/MyMetamodel.ecore#//ECla ssA "/>
>
So it's referring to the serialized development time version...
> or
>
> <eClassifiers xsi:type="ecore:EClass" xmi:id="_Q0PN8BixEeClyuEUzwXIhg"
> name="EClassB"
> eSuperTypes="../../my.plugin.id/model/MyMetamodel.ecore#//EClassA "/>
>
This might refer to one in the workspace or in the running IDE depending
on the URI used to load the resource containing this.
> (depending on whether I loaded the referenced metamodel within the Ecore
> editor through "Browse registered packages" or "Browse workspace"). I
> would have expected the actual nsUri of the referenced metamodel here -
> could this be the problem? (I tried to "repair" the according references
> textually, but I can't reload the related genmodel any more).
>
You've never talked about how this problem comes up. You need to
consistently use the development time version when you're wanting to
generate it. It sounds like there are cases where you're using the
actually running instance in the IDE itself. Without some background
about what you're doing and how you got there it's hard to give advice.
> Thanks in advance for your help,
> Chris
>
>
>
--------------080607030407040108020102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
Comments below.<br>
<br>
Chris wrote:
<blockquote cite="mid:ig3ttf$uea$1@news.eclipse.org" type="cite">
<pre wrap="">Dear Ed,
thanks for your fast and helpful reply...
Am 04.01.2011 17:01, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I have a strange problem: Sometimes, checks like
eClassA.isSuperType(eClassB) fail unexpectedly. Debugging revealed that
the supertypes of eClassB indeed contain an instance of EClassA;
however, it's a different instance than eClassA. Since isSuperType()
relies on comparison of the object references (i.e., it will be checked
whether eClass1 == eClass2), the method "fails".
My Problem is that I have no idea why there would be different instances
of the same EClass hanging around in my system. All involved metamodels
seem to be registered fine... Has anybody seen something like this
before, or has any idea why that happens?
</pre>
</blockquote>
<pre wrap="">Have you checked eClassA.getEPackage().eResource().getURI(). If it's a
loaded package the containing resource's URI will tell you where it's
loaded from. You might set a conditional breakpoint in
EPackageImpl.setNsURI, checking for the nsURI of the package you know is
being loaded, to see what's causing it to be loaded.
</pre>
</blockquote>
<pre wrap=""><!---->
If I get you right, then EPackageImpl.setNsUri should only be called
when the init method of my metamodel's package class is called.</pre>
</blockquote>
It could also happen when you deserialize one<br>
<blockquote cite="mid:ig3ttf$uea$1@news.eclipse.org" type="cite">
<pre wrap=""> This was
quite helpful - it turned out that the package is indeed loaded again.
However, I'm not sure why this happens.
</pre>
</blockquote>
The stack should help answer that.<br>
<blockquote cite="mid:ig3ttf$uea$1@news.eclipse.org" type="cite">
<pre wrap="">
The problem occurs when calling EClass.getEAllSupertypes. The class I'm
calling on seems to be fine according to this code:
EPackage ePackage =
EPackage.Registry.INSTANCE.getEPackage(eclass.getEPackage(). getNsURI());
EClassifier registeredClassifier =
ePackage.getEClassifier(eclass.getName());
Afterwards, registeredClassifier == eclass. However, the package is
loaded again during getEAllSuperTypes - the resulting EClasses indeed
contain one class such that the above check fails.
</pre>
</blockquote>
So some other model is referencing a different version of it.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with different instances of the same EClass [message #647601 is a reply to message #647496] |
Fri, 07 January 2011 09:26 |
chris
Messages: 72
Registered: July 2009 |
Member |
|
|
Dear Ed,
once again thanks for your help and your patience...
Am 06.01.2011 17:44, schrieb Ed Merks:
> You've never talked about how this problem comes up. You need to
> consistently use the development time version when you're wanting to
> generate it. It sounds like there are cases where you're using the
> actually running instance in the IDE itself. Without some background
> about what you're doing and how you got there it's hard to give advice.
Sorry for that - I tried to provide only as much information as needed,
which apparently didn't work out.
Here's what I try to do: I have an Ecore metamodel M1 containing, say,
EClass A and B (in fact, there are more metamodels involved, but I hope
this suffices to explain my problem). I have another Ecore metamodel M2
containing EClass C and D, such that C is a subtype of A, and D has an
EReference of type B. Now, I instantiate M1, getting a model m1
containing objects a and b, and I instantiate M2, getting m2 containing
objects c and d, where d references b. I now want to traverse model m2
and, depending on the supertypes and other relations of my objects in
m2, create another datastructure (this is not important here).
I tried to do that as follows:
First, I create metamodel M1 in its own EMF project. Then, I launch the
runtime workbench. I create a new EMF project containing M2. Then, I
load the resource M1 by using "Browse Generated Packages", and I add A
to the supertypes of C and type D's reference.
I then close the runtime workbench, import the created project into the
development workspace (by copy), generate the edit and editor plugins
and restart the runtime workbench. I now use the generated editors to
first create m1. Then I create m2, loading m1 by browsing my runtime
workspace.
Finally, I execute my code by selecting m2 in the Runtime workspace and
launching my command. The code receives the selected IFile, loads m2 and
starts to examine it. This is where things go wrong (i.e., the
getEAllSupertypes call fails as described earlier in the thread).
The reason I did that was that I assumed that "Browse Generated
Packages" will make sure that my metamodel M2 refers to the unique
registered metamodel M1. That's why I didn't bother about importing the
projects into my development workspace to have the EMF tooling available
in the runtime workspace.
However, it seems that his was a wrong assumption: As you have figured
out, when loading m2, the EPackage of M1 is loaded again from the
platform URI instead of being received from the EPackage registry - this
is where my different EClass instances come from.
However, I'm not sure how to solve my problem - I'm a bit lost between
all those URIHandlers, URIConverters etc. :-)
Thanks in advance for your advice,
Chris
--
Larry Gelbart: "One doesn't have a sense of humor. It has you."
|
|
| |
| Re: Problem with different instances of the same EClass [message #647663 is a reply to message #647601] |
Fri, 07 January 2011 16:36 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020608020107060700040107
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Chris,
Comments below.
Chris wrote:
> Dear Ed,
>
> once again thanks for your help and your patience...
>
> Am 06.01.2011 17:44, schrieb Ed Merks:
>
>> You've never talked about how this problem comes up. You need to
>> consistently use the development time version when you're wanting to
>> generate it. It sounds like there are cases where you're using the
>> actually running instance in the IDE itself. Without some background
>> about what you're doing and how you got there it's hard to give advice.
>>
>
> Sorry for that - I tried to provide only as much information as needed,
> which apparently didn't work out.
>
> Here's what I try to do: I have an Ecore metamodel M1 containing, say,
> EClass A and B (in fact, there are more metamodels involved, but I hope
> this suffices to explain my problem). I have another Ecore metamodel M2
> containing EClass C and D, such that C is a subtype of A, and D has an
> EReference of type B. Now, I instantiate M1, getting a model m1
> containing objects a and b, and I instantiate M2, getting m2 containing
> objects c and d, where d references b.
Have these models (M1 and M2) been generated? Or are you using dynamic
versions of M1 and M2.
> I now want to traverse model m2
> and, depending on the supertypes and other relations of my objects in
> m2, create another datastructure (this is not important here).
>
> I tried to do that as follows:
> First, I create metamodel M1 in its own EMF project. Then, I launch the
> runtime workbench. I create a new EMF project containing M2. Then, I
> load the resource M1 by using "Browse Generated Packages", and I add A
> to the supertypes of C and type D's reference.
>
So M2 is referring to the development time instance of M1 which is part
of the running IDE that's being used to develop M2.
> I then close the runtime workbench, import the created project into the
> development workspace (by copy), generate the edit and editor plugins
> and restart the runtime workbench.
Why these elaborate steps? Why didn't you just build M2 in the same
workbench to begin with. This sounds problematic now because M2
references M1 as if it were installed in the IDE, but in this original
IDE there is no M1 installed, so something is going to be broken? EMF
will redirect M2's references to M1 into the workspace version so you
might not notice it's a little odd...
> I now use the generated editors to
> first create m1. Then I create m2, loading m1 by browsing my runtime
> workspace.
>
So it should be an m2 based on the generated M2...
> Finally, I execute my code by selecting m2 in the Runtime workspace and
> launching my command. The code receives the selected IFile, loads m2 and
> starts to examine it. This is where things go wrong (i.e., the
> getEAllSupertypes call fails as described earlier in the thread).
>
You've set breakpoints to see when each EPackage's nsURI is set to see
why more than one instance of M2 is being created... Looking at the
stack when the breakpoint is hit should be very helpful.
> The reason I did that was that I assumed that "Browse Generated
> Packages"
You mean Browse Registered Packages? And you picked the development
time version?
> will make sure that my metamodel M2 refers to the unique
> registered metamodel M1. That's why I didn't bother about importing the
> projects into my development workspace to have the EMF tooling available
> in the runtime workspace.
>
It sounds like you're doing way too much strange stuff just for building
an M2 that depends on M1. I'd expect you do deal with M2 exactly how
you did with M1 and that you'd use Browse Workspace... to load M1 into
M2's editor so you can set up the super types and references.
> However, it seems that his was a wrong assumption: As you have figured
> out, when loading m2, the EPackage of M1 is loaded again from the
> platform URI instead of being received from the EPackage registry - this
> is where my different EClass instances come from.
>
Do you instances have xsi:schemaLocations in them?
> However, I'm not sure how to solve my problem - I'm a bit lost between
> all those URIHandlers, URIConverters etc. :-)
>
> Thanks in advance for your advice,
> Chris
>
>
>
--------------020608020107060700040107
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
Comments below.<br>
<br>
Chris wrote:
<blockquote cite="mid:ig6ltc$jl2$1@news.eclipse.org" type="cite">
<pre wrap="">Dear Ed,
once again thanks for your help and your patience...
Am 06.01.2011 17:44, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<pre wrap="">You've never talked about how this problem comes up. You need to
consistently use the development time version when you're wanting to
generate it. It sounds like there are cases where you're using the
actually running instance in the IDE itself. Without some background
about what you're doing and how you got there it's hard to give advice.
</pre>
</blockquote>
<pre wrap=""><!---->
Sorry for that - I tried to provide only as much information as needed,
which apparently didn't work out.
Here's what I try to do: I have an Ecore metamodel M1 containing, say,
EClass A and B (in fact, there are more metamodels involved, but I hope
this suffices to explain my problem). I have another Ecore metamodel M2
containing EClass C and D, such that C is a subtype of A, and D has an
EReference of type B. Now, I instantiate M1, getting a model m1
containing objects a and b, and I instantiate M2, getting m2 containing
objects c and d, where d references b.</pre>
</blockquote>
Have these models (M1 and M2) been generated?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 09:09:22 GMT 2024
Powered by FUDForum. Page generated in 0.03244 seconds |
] 
Search
Help
Register
Login
Home
