Home » Modeling » OCL » Re: EClass defined in ecore model not (always) loaded correctly
| Re: EClass defined in ecore model not (always) loaded correctly [message #67944] |
Thu, 19 February 2009 10:06  |
 Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
Hi (I cc'd the OCL newsgroup this time),
I (think) I gained a little more insight in the last hours. In
particular, I learned the following:
-) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
OCL_INVALID that is returned when evaluation of a query fails. In my
case, it fails because it doesn't find the property it looks for.
-) In my ecore model, I have a class MyClass, and it has an attribute
'name'. Furthermore I have a subclass MySubClass which extends MyClass.
Now, it seems that calling the attribute 'name' was a very bad decision
because class ENamedElement has already an attribute called 'name'.
-) MyClass does not extend EObject direclty in the model, but of course
the generated code will extend EObject...
-) Due to some "miracles", I can use eContainer() and all other
properties of EObject in my OCL expressions used to specify
constraints, derived features and operation bodies.
-) Of course I can also use the 'name' property of MySubClass. Now it's
getting less funny however, because when evaluating an OCL expression
that uses the 'name' property, it will sometimes use the 'name'
property of MySubClass, which is correct. But sometimes, it tries to
use the 'name' property of ENamedElement, and then it fails because
this property does not exist on the model level in MySubClass.
I had all these experiences using M4 milestones.
Now I'm curious to know:
-) why it seems to be random instead of always working or always failing?
-) whether making MyClass extend EObject directly in the model is a
good solution or if there are better/different ones? Always given that
I want to have a 'name' attribute :-)
All the best,
Marc
On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
> Hi,
>
> I have a very strange problem in the application I'm currently
> developing. I use EMF/Ecore to model all parts of the application.
> Furthermore, I have adapted the EMF templates such that I can use OCL
> to specify operation bodies, derived features/attributes and labels
> (this redefines the getText() in the EditProviders). In principle,
> everything works fine, but I randomly get an IllegalArgumentException
> thrown from OCL (see stack trace below). It really seems to be
> completely random; I open a resource, it works, I close and reopen it
> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
> only works 3 out of 10 times I try it.
>
> Now, the only thing I could figure out was that there seems to be
> exactly one class that is not always correctly loaded. Whenever it
> works, instances of that class (call it MyClass) are shown with the
> correct label in the tree editor. Whenever it doesn't work, instances
> of MyClass are displayed as
> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
> MyClass is unknown to the system and some dynamic object is created in
> this case. Then, all OCL expressions which use myPackage::myClass (e.g.
> accessing features of it) fail with the IllegalArgumentException, which
> somehow makes sense because the class seems to be unknown. Thus, it
> seems to be more a EMF issue than an OCL problem.
>
> Does anyone have an idea why my class is "sometimes" not known? It is
> also very strange that all the other classes defined in the same (or in
> different) packages have no problem at all.
>
> Or does someone have a hint how I could debug this problem?
>
> Many thanks!
>
> Best,
> Marc
>
> !MESSAGE Evaluation failed with an exception: (no message)
> !STACK 0
> java.lang.IllegalArgumentException
> at
> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
at
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
at
org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
at
org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
at
org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
at
org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
at
>
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
at
org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
at
>
> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
at
org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
at
>
> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #67966 is a reply to message #67944] |
Thu, 19 February 2009 11:44  |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Marc,
My guess would be that package of the class with the problems isn't
properly registered by a generated_package or dynamic_package extension
point so that perhaps. Make sure that whatever model you define, that
it validated correctly. I.e., that Diagnostician.INSTANCE.validate
returns true for the package.
Marc Moser wrote:
> Hi (I cc'd the OCL newsgroup this time),
>
> I (think) I gained a little more insight in the last hours. In
> particular, I learned the following:
>
> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
> OCL_INVALID that is returned when evaluation of a query fails. In my
> case, it fails because it doesn't find the property it looks for.
>
> -) In my ecore model, I have a class MyClass, and it has an attribute
> 'name'. Furthermore I have a subclass MySubClass which extends
> MyClass. Now, it seems that calling the attribute 'name' was a very
> bad decision because class ENamedElement has already an attribute
> called 'name'.
>
> -) MyClass does not extend EObject direclty in the model, but of
> course the generated code will extend EObject...
>
> -) Due to some "miracles", I can use eContainer() and all other
> properties of EObject in my OCL expressions used to specify
> constraints, derived features and operation bodies.
>
> -) Of course I can also use the 'name' property of MySubClass. Now
> it's getting less funny however, because when evaluating an OCL
> expression that uses the 'name' property, it will sometimes use the
> 'name' property of MySubClass, which is correct. But sometimes, it
> tries to use the 'name' property of ENamedElement, and then it fails
> because this property does not exist on the model level in MySubClass.
>
> I had all these experiences using M4 milestones.
>
> Now I'm curious to know:
>
> -) why it seems to be random instead of always working or always failing?
>
> -) whether making MyClass extend EObject directly in the model is a
> good solution or if there are better/different ones? Always given that
> I want to have a 'name' attribute :-)
>
> All the best,
> Marc
>
> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>
>> Hi,
>>
>> I have a very strange problem in the application I'm currently
>> developing. I use EMF/Ecore to model all parts of the application.
>> Furthermore, I have adapted the EMF templates such that I can use OCL
>> to specify operation bodies, derived features/attributes and labels
>> (this redefines the getText() in the EditProviders). In principle,
>> everything works fine, but I randomly get an IllegalArgumentException
>> thrown from OCL (see stack trace below). It really seems to be
>> completely random; I open a resource, it works, I close and reopen it
>> again, it doesn't work... sometimes it works 8 out of 10, sometimes
>> it only works 3 out of 10 times I try it.
>>
>> Now, the only thing I could figure out was that there seems to be
>> exactly one class that is not always correctly loaded. Whenever it
>> works, instances of that class (call it MyClass) are shown with the
>> correct label in the tree editor. Whenever it doesn't work, instances
>> of MyClass are displayed as
>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>> MyClass is unknown to the system and some dynamic object is created
>> in this case. Then, all OCL expressions which use myPackage::myClass
>> (e.g. accessing features of it) fail with the
>> IllegalArgumentException, which somehow makes sense because the class
>> seems to be unknown. Thus, it seems to be more a EMF issue than an
>> OCL problem.
>>
>> Does anyone have an idea why my class is "sometimes" not known? It is
>> also very strange that all the other classes defined in the same (or
>> in different) packages have no problem at all.
>>
>> Or does someone have a hint how I could debug this problem?
>>
>> Many thanks!
>>
>> Best,
>> Marc
>>
>> !MESSAGE Evaluation failed with an exception: (no message)
>> !STACK 0
>> java.lang.IllegalArgumentException
>> at
>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>
> at
> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>
> at
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>
> at
> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>
> at
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>
> at
> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
> at
>>
>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>
> at
> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
> at
>>
>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>
> at
> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>
> at
>>
>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68008 is a reply to message #67944] |
Thu, 19 February 2009 12:36 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Marc,
This is strange. Yes, the OclInvalid results from the
IllegalArgumentException raised by the interpreter on attempting to
navigate the 'name' property that doesn't exist.
I'm pretty sure that the problem is in the definition of your Ecore
model, or the way in which it is loaded. Unless, of course, you are
parsing the OCL expression in the context of ENamedElement and then
evaluating it on instances of MyClass? Maybe the non-determinism is in
the selection of the context for the parsing of the expression ...
Cheers,
Christian
Marc Moser wrote:
> Hi (I cc'd the OCL newsgroup this time),
>
> I (think) I gained a little more insight in the last hours. In
> particular, I learned the following:
>
> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
> OCL_INVALID that is returned when evaluation of a query fails. In my
> case, it fails because it doesn't find the property it looks for.
>
> -) In my ecore model, I have a class MyClass, and it has an attribute
> 'name'. Furthermore I have a subclass MySubClass which extends MyClass.
> Now, it seems that calling the attribute 'name' was a very bad decision
> because class ENamedElement has already an attribute called 'name'.
>
> -) MyClass does not extend EObject direclty in the model, but of course
> the generated code will extend EObject...
>
> -) Due to some "miracles", I can use eContainer() and all other
> properties of EObject in my OCL expressions used to specify
> constraints, derived features and operation bodies.
>
> -) Of course I can also use the 'name' property of MySubClass. Now it's
> getting less funny however, because when evaluating an OCL expression
> that uses the 'name' property, it will sometimes use the 'name' property
> of MySubClass, which is correct. But sometimes, it tries to use the
> 'name' property of ENamedElement, and then it fails because this
> property does not exist on the model level in MySubClass.
>
> I had all these experiences using M4 milestones.
>
> Now I'm curious to know:
>
> -) why it seems to be random instead of always working or always failing?
>
> -) whether making MyClass extend EObject directly in the model is a good
> solution or if there are better/different ones? Always given that I want
> to have a 'name' attribute :-)
>
> All the best,
> Marc
>
> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>
>> Hi,
>>
>> I have a very strange problem in the application I'm currently
>> developing. I use EMF/Ecore to model all parts of the application.
>> Furthermore, I have adapted the EMF templates such that I can use OCL
>> to specify operation bodies, derived features/attributes and labels
>> (this redefines the getText() in the EditProviders). In principle,
>> everything works fine, but I randomly get an IllegalArgumentException
>> thrown from OCL (see stack trace below). It really seems to be
>> completely random; I open a resource, it works, I close and reopen it
>> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
>> only works 3 out of 10 times I try it.
>>
>> Now, the only thing I could figure out was that there seems to be
>> exactly one class that is not always correctly loaded. Whenever it
>> works, instances of that class (call it MyClass) are shown with the
>> correct label in the tree editor. Whenever it doesn't work, instances
>> of MyClass are displayed as
>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>> MyClass is unknown to the system and some dynamic object is created in
>> this case. Then, all OCL expressions which use myPackage::myClass
>> (e.g. accessing features of it) fail with the
>> IllegalArgumentException, which somehow makes sense because the class
>> seems to be unknown. Thus, it seems to be more a EMF issue than an OCL
>> problem.
>>
>> Does anyone have an idea why my class is "sometimes" not known? It is
>> also very strange that all the other classes defined in the same (or
>> in different) packages have no problem at all.
>>
>> Or does someone have a hint how I could debug this problem?
>>
>> Many thanks!
>>
>> Best,
>> Marc
>>
>> !MESSAGE Evaluation failed with an exception: (no message)
>> !STACK 0
>> java.lang.IllegalArgumentException
>> at
>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>
> at
> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>
> at
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>
> at
> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>
> at
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>
> at
> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
> at
>>
>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>
> at
> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
> at
>>
>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>
> at
> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
> at
>>
>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68027 is a reply to message #68008] |
Thu, 19 February 2009 13:58 |
Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
Hi Ed, Christian,
Thanks for your support!
I think the package is loaded correctly. Especially because all other
classes work well. In principle, all expressions using the 'name'
attribute fail, all other expressions evaluate well. But I must admit I
didn't validate the model ._. I'll check this!
The problem finally manifests itself in the operation Object
navigateProperty(property, qualifiers, target). The target is an
instance of 'MySubClass', the qualifiers list is empty, but the
property is not the 'name' attribute of 'MyClass' but the 'name'
attribute of 'ENamedElement'. Well, it isn't in about half of the
cases, in the other half the property really is the 'name' attribute of
'MyClass'.
I'll have a deeper look later today and try to create an example that I
can share.
Note also that I "solved" the problem in my case by removing the 'name'
attribute from 'MyClass' and making 'MyClass' extend 'ENamedElement'.
Best,
Marc
On 2009-02-19 13:36:36 +0100, "Christian W. Damus" <cdamus@zeligsoft.com> said:
> Hi, Marc,
>
> This is strange. Yes, the OclInvalid results from the
> IllegalArgumentException raised by the interpreter on attempting to
> navigate the 'name' property that doesn't exist.
>
> I'm pretty sure that the problem is in the definition of your Ecore
> model, or the way in which it is loaded. Unless, of course, you are
> parsing the OCL expression in the context of ENamedElement and then
> evaluating it on instances of MyClass? Maybe the non-determinism is in
> the selection of the context for the parsing of the expression ...
>
> Cheers,
>
> Christian
>
>
> Marc Moser wrote:
>> Hi (I cc'd the OCL newsgroup this time),
>>
>> I (think) I gained a little more insight in the last hours. In
>> particular, I learned the following:
>>
>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
>> OCL_INVALID that is returned when evaluation of a query fails. In my
>> case, it fails because it doesn't find the property it looks for.
>>
>> -) In my ecore model, I have a class MyClass, and it has an attribute
>> 'name'. Furthermore I have a subclass MySubClass which extends MyClass.
>> Now, it seems that calling the attribute 'name' was a very bad decision
>> because class ENamedElement has already an attribute called 'name'.
>>
>> -) MyClass does not extend EObject direclty in the model, but of course
>> the generated code will extend EObject...
>>
>> -) Due to some "miracles", I can use eContainer() and all other
>> properties of EObject in my OCL expressions used to specify
>> constraints, derived features and operation bodies.
>>
>> -) Of course I can also use the 'name' property of MySubClass. Now it's
>> getting less funny however, because when evaluating an OCL expression
>> that uses the 'name' property, it will sometimes use the 'name'
>> property of MySubClass, which is correct. But sometimes, it tries to
>> use the 'name' property of ENamedElement, and then it fails because
>> this property does not exist on the model level in MySubClass.
>>
>> I had all these experiences using M4 milestones.
>>
>> Now I'm curious to know:
>>
>> -) why it seems to be random instead of always working or always failing?
>>
>> -) whether making MyClass extend EObject directly in the model is a
>> good solution or if there are better/different ones? Always given that
>> I want to have a 'name' attribute :-)
>>
>> All the best,
>> Marc
>>
>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>
>>> Hi,
>>>
>>> I have a very strange problem in the application I'm currently
>>> developing. I use EMF/Ecore to model all parts of the application.
>>> Furthermore, I have adapted the EMF templates such that I can use OCL
>>> to specify operation bodies, derived features/attributes and labels
>>> (this redefines the getText() in the EditProviders). In principle,
>>> everything works fine, but I randomly get an IllegalArgumentException
>>> thrown from OCL (see stack trace below). It really seems to be
>>> completely random; I open a resource, it works, I close and reopen it
>>> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
>>> only works 3 out of 10 times I try it.
>>>
>>> Now, the only thing I could figure out was that there seems to be
>>> exactly one class that is not always correctly loaded. Whenever it
>>> works, instances of that class (call it MyClass) are shown with the
>>> correct label in the tree editor. Whenever it doesn't work, instances
>>> of MyClass are displayed as
>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>>> MyClass is unknown to the system and some dynamic object is created in
>>> this case. Then, all OCL expressions which use myPackage::myClass (e.g.
>>> accessing features of it) fail with the IllegalArgumentException, which
>>> somehow makes sense because the class seems to be unknown. Thus, it
>>> seems to be more a EMF issue than an OCL problem.
>>>
>>> Does anyone have an idea why my class is "sometimes" not known? It is
>>> also very strange that all the other classes defined in the same (or in
>>> different) packages have no problem at all.
>>>
>>> Or does someone have a hint how I could debug this problem?
>>>
>>> Many thanks!
>>>
>>> Best,
>>> Marc
>>>
>>> !MESSAGE Evaluation failed with an exception: (no message)
>>> !STACK 0
>>> java.lang.IllegalArgumentException
>>> at
>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>
>> at
>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>
>> at
>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>
>> at
>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>
>> at
>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>
>> at
>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>> at
>>>
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>
>> at
>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>> at
>>>
>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>
>> at
>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>> at
>>>
>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68048 is a reply to message #68027] |
Thu, 19 February 2009 17:46 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Marc,
See some comments in-line, below.
HTH,
Christian
Marc Moser wrote:
> Hi Ed, Christian,
>
> Thanks for your support!
>
> I think the package is loaded correctly. Especially because all other
> classes work well. In principle, all expressions using the 'name'
> attribute fail, all other expressions evaluate well. But I must admit I
> didn't validate the model ._. I'll check this!
>
> The problem finally manifests itself in the operation Object
> navigateProperty(property, qualifiers, target). The target is an
> instance of 'MySubClass', the qualifiers list is empty, but the property
> is not the 'name' attribute of 'MyClass' but the 'name' attribute of
> 'ENamedElement'. Well, it isn't in about half of the cases, in the other
> half the property really is the 'name' attribute of 'MyClass'.
Right. The problem isn't in this method, though, nor in the interpreter
(EvaluationVisitor) at all. The interpreter only evaluates the
expression as it was parsed, and the problem is that the parser found
the ENamedElement::name attribute instead of MyClass::name. The usual
reason for this would be parsing the constraint in the context of some
EClass that inherits ENamedElement::name instead of MyClass::name.
> I'll have a deeper look later today and try to create an example that I
> can share.
>
> Note also that I "solved" the problem in my case by removing the 'name'
> attribute from 'MyClass' and making 'MyClass' extend 'ENamedElement'.
Don't do that! That will just get Ed on your case about extending Ecore
:-P
>
> Best,
> Marc
>
> On 2009-02-19 13:36:36 +0100, "Christian W. Damus"
> <cdamus@zeligsoft.com> said:
>
>> Hi, Marc,
>>
>> This is strange. Yes, the OclInvalid results from the
>> IllegalArgumentException raised by the interpreter on attempting to
>> navigate the 'name' property that doesn't exist.
>>
>> I'm pretty sure that the problem is in the definition of your Ecore
>> model, or the way in which it is loaded. Unless, of course, you are
>> parsing the OCL expression in the context of ENamedElement and then
>> evaluating it on instances of MyClass? Maybe the non-determinism is
>> in the selection of the context for the parsing of the expression ...
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Marc Moser wrote:
>>> Hi (I cc'd the OCL newsgroup this time),
>>>
>>> I (think) I gained a little more insight in the last hours. In
>>> particular, I learned the following:
>>>
>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is
>>> actually OCL_INVALID that is returned when evaluation of a query
>>> fails. In my case, it fails because it doesn't find the property it
>>> looks for.
>>>
>>> -) In my ecore model, I have a class MyClass, and it has an attribute
>>> 'name'. Furthermore I have a subclass MySubClass which extends
>>> MyClass. Now, it seems that calling the attribute 'name' was a very
>>> bad decision because class ENamedElement has already an attribute
>>> called 'name'.
>>>
>>> -) MyClass does not extend EObject direclty in the model, but of
>>> course the generated code will extend EObject...
>>>
>>> -) Due to some "miracles", I can use eContainer() and all other
>>> properties of EObject in my OCL expressions used to specify
>>> constraints, derived features and operation bodies.
>>>
>>> -) Of course I can also use the 'name' property of MySubClass. Now
>>> it's getting less funny however, because when evaluating an OCL
>>> expression that uses the 'name' property, it will sometimes use the
>>> 'name' property of MySubClass, which is correct. But sometimes, it
>>> tries to use the 'name' property of ENamedElement, and then it fails
>>> because this property does not exist on the model level in MySubClass.
>>>
>>> I had all these experiences using M4 milestones.
>>>
>>> Now I'm curious to know:
>>>
>>> -) why it seems to be random instead of always working or always
>>> failing?
>>>
>>> -) whether making MyClass extend EObject directly in the model is a
>>> good solution or if there are better/different ones? Always given
>>> that I want to have a 'name' attribute :-)
>>>
>>> All the best,
>>> Marc
>>>
>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>
>>>> Hi,
>>>>
>>>> I have a very strange problem in the application I'm currently
>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>> Furthermore, I have adapted the EMF templates such that I can use
>>>> OCL to specify operation bodies, derived features/attributes and
>>>> labels (this redefines the getText() in the EditProviders). In
>>>> principle, everything works fine, but I randomly get an
>>>> IllegalArgumentException thrown from OCL (see stack trace below). It
>>>> really seems to be completely random; I open a resource, it works, I
>>>> close and reopen it again, it doesn't work... sometimes it works 8
>>>> out of 10, sometimes it only works 3 out of 10 times I try it.
>>>>
>>>> Now, the only thing I could figure out was that there seems to be
>>>> exactly one class that is not always correctly loaded. Whenever it
>>>> works, instances of that class (call it MyClass) are shown with the
>>>> correct label in the tree editor. Whenever it doesn't work,
>>>> instances of MyClass are displayed as
>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>>>> MyClass is unknown to the system and some dynamic object is created
>>>> in this case. Then, all OCL expressions which use myPackage::myClass
>>>> (e.g. accessing features of it) fail with the
>>>> IllegalArgumentException, which somehow makes sense because the
>>>> class seems to be unknown. Thus, it seems to be more a EMF issue
>>>> than an OCL problem.
>>>>
>>>> Does anyone have an idea why my class is "sometimes" not known? It
>>>> is also very strange that all the other classes defined in the same
>>>> (or in different) packages have no problem at all.
>>>>
>>>> Or does someone have a hint how I could debug this problem?
>>>>
>>>> Many thanks!
>>>>
>>>> Best,
>>>> Marc
>>>>
>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>> !STACK 0
>>>> java.lang.IllegalArgumentException
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>> at
>>>>
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>> at
>>>>
>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>
>>> at
>>>>
>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68067 is a reply to message #68048] |
Thu, 19 February 2009 18:53 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Christian,
Extending Ecore. Sigh...
Christian W. Damus wrote:
> Hi, Marc,
>
> See some comments in-line, below.
>
> HTH,
>
> Christian
>
> Marc Moser wrote:
>> Hi Ed, Christian,
>>
>> Thanks for your support!
>>
>> I think the package is loaded correctly. Especially because all other
>> classes work well. In principle, all expressions using the 'name'
>> attribute fail, all other expressions evaluate well. But I must admit
>> I didn't validate the model ._. I'll check this!
>>
>> The problem finally manifests itself in the operation Object
>> navigateProperty(property, qualifiers, target). The target is an
>> instance of 'MySubClass', the qualifiers list is empty, but the
>> property is not the 'name' attribute of 'MyClass' but the 'name'
>> attribute of 'ENamedElement'. Well, it isn't in about half of the
>> cases, in the other half the property really is the 'name' attribute
>> of 'MyClass'.
>
> Right. The problem isn't in this method, though, nor in the
> interpreter (EvaluationVisitor) at all. The interpreter only
> evaluates the expression as it was parsed, and the problem is that the
> parser found the ENamedElement::name attribute instead of
> MyClass::name. The usual reason for this would be parsing the
> constraint in the context of some EClass that inherits
> ENamedElement::name instead of MyClass::name.
>
>
>> I'll have a deeper look later today and try to create an example that
>> I can share.
>>
>> Note also that I "solved" the problem in my case by removing the
>> 'name' attribute from 'MyClass' and making 'MyClass' extend
>> 'ENamedElement'.
>
> Don't do that! That will just get Ed on your case about extending
> Ecore :-P
>
>
>>
>> Best,
>> Marc
>>
>> On 2009-02-19 13:36:36 +0100, "Christian W. Damus"
>> <cdamus@zeligsoft.com> said:
>>
>>> Hi, Marc,
>>>
>>> This is strange. Yes, the OclInvalid results from the
>>> IllegalArgumentException raised by the interpreter on attempting to
>>> navigate the 'name' property that doesn't exist.
>>>
>>> I'm pretty sure that the problem is in the definition of your Ecore
>>> model, or the way in which it is loaded. Unless, of course, you are
>>> parsing the OCL expression in the context of ENamedElement and then
>>> evaluating it on instances of MyClass? Maybe the non-determinism is
>>> in the selection of the context for the parsing of the expression ...
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Marc Moser wrote:
>>>> Hi (I cc'd the OCL newsgroup this time),
>>>>
>>>> I (think) I gained a little more insight in the last hours. In
>>>> particular, I learned the following:
>>>>
>>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is
>>>> actually OCL_INVALID that is returned when evaluation of a query
>>>> fails. In my case, it fails because it doesn't find the property it
>>>> looks for.
>>>>
>>>> -) In my ecore model, I have a class MyClass, and it has an
>>>> attribute 'name'. Furthermore I have a subclass MySubClass which
>>>> extends MyClass. Now, it seems that calling the attribute 'name'
>>>> was a very bad decision because class ENamedElement has already an
>>>> attribute called 'name'.
>>>>
>>>> -) MyClass does not extend EObject direclty in the model, but of
>>>> course the generated code will extend EObject...
>>>>
>>>> -) Due to some "miracles", I can use eContainer() and all other
>>>> properties of EObject in my OCL expressions used to specify
>>>> constraints, derived features and operation bodies.
>>>>
>>>> -) Of course I can also use the 'name' property of MySubClass. Now
>>>> it's getting less funny however, because when evaluating an OCL
>>>> expression that uses the 'name' property, it will sometimes use the
>>>> 'name' property of MySubClass, which is correct. But sometimes, it
>>>> tries to use the 'name' property of ENamedElement, and then it
>>>> fails because this property does not exist on the model level in
>>>> MySubClass.
>>>>
>>>> I had all these experiences using M4 milestones.
>>>>
>>>> Now I'm curious to know:
>>>>
>>>> -) why it seems to be random instead of always working or always
>>>> failing?
>>>>
>>>> -) whether making MyClass extend EObject directly in the model is a
>>>> good solution or if there are better/different ones? Always given
>>>> that I want to have a 'name' attribute :-)
>>>>
>>>> All the best,
>>>> Marc
>>>>
>>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a very strange problem in the application I'm currently
>>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>>> Furthermore, I have adapted the EMF templates such that I can use
>>>>> OCL to specify operation bodies, derived features/attributes and
>>>>> labels (this redefines the getText() in the EditProviders). In
>>>>> principle, everything works fine, but I randomly get an
>>>>> IllegalArgumentException thrown from OCL (see stack trace below).
>>>>> It really seems to be completely random; I open a resource, it
>>>>> works, I close and reopen it again, it doesn't work... sometimes
>>>>> it works 8 out of 10, sometimes it only works 3 out of 10 times I
>>>>> try it.
>>>>>
>>>>> Now, the only thing I could figure out was that there seems to be
>>>>> exactly one class that is not always correctly loaded. Whenever it
>>>>> works, instances of that class (call it MyClass) are shown with
>>>>> the correct label in the tree editor. Whenever it doesn't work,
>>>>> instances of MyClass are displayed as
>>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems
>>>>> that MyClass is unknown to the system and some dynamic object is
>>>>> created in this case. Then, all OCL expressions which use
>>>>> myPackage::myClass (e.g. accessing features of it) fail with the
>>>>> IllegalArgumentException, which somehow makes sense because the
>>>>> class seems to be unknown. Thus, it seems to be more a EMF issue
>>>>> than an OCL problem.
>>>>>
>>>>> Does anyone have an idea why my class is "sometimes" not known? It
>>>>> is also very strange that all the other classes defined in the
>>>>> same (or in different) packages have no problem at all.
>>>>>
>>>>> Or does someone have a hint how I could debug this problem?
>>>>>
>>>>> Many thanks!
>>>>>
>>>>> Best,
>>>>> Marc
>>>>>
>>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>>> !STACK 0
>>>>> java.lang.IllegalArgumentException
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>>
>>
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>>
>>
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>>
>>
>>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>>
>>>> at
>>>>>
>>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68084 is a reply to message #68067] |
Fri, 20 February 2009 14:18 |
Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
I extended ENamedElement because I didn't want to change the name of my
attribute, and thought it would be ok as a quickfix, because changing
the name of the attribute means to adapt all the OCL expressions, and
worse all the test resources.
As it turned out, even as a quickfix extending Ecore is not a good
idea, because business names do not tend to be "well formed" as the
name attribute of ENamedElement enforces ;-)
Maybe the next version of the EMF book should have "Do not extend
Ecore" written on the cover :-P
> Christian,
>
> Extending Ecore. Sigh...
>
>
> Christian W. Damus wrote:
>> Hi, Marc,
>>
>> See some comments in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>> Marc Moser wrote:
>>> Hi Ed, Christian,
>>>
>>> Thanks for your support!
>>>
>>> I think the package is loaded correctly. Especially because all other
>>> classes work well. In principle, all expressions using the 'name'
>>> attribute fail, all other expressions evaluate well. But I must admit I
>>> didn't validate the model ._. I'll check this!
>>>
>>> The problem finally manifests itself in the operation Object
>>> navigateProperty(property, qualifiers, target). The target is an
>>> instance of 'MySubClass', the qualifiers list is empty, but the
>>> property is not the 'name' attribute of 'MyClass' but the 'name'
>>> attribute of 'ENamedElement'. Well, it isn't in about half of the
>>> cases, in the other half the property really is the 'name' attribute of
>>> 'MyClass'.
>>
>> Right. The problem isn't in this method, though, nor in the
>> interpreter (EvaluationVisitor) at all. The interpreter only evaluates
>> the expression as it was parsed, and the problem is that the parser
>> found the ENamedElement::name attribute instead of MyClass::name. The
>> usual reason for this would be parsing the constraint in the context of
>> some EClass that inherits ENamedElement::name instead of MyClass::name.
>>
>>
>>> I'll have a deeper look later today and try to create an example that I
>>> can share.
>>>
>>> Note also that I "solved" the problem in my case by removing the 'name'
>>> attribute from 'MyClass' and making 'MyClass' extend 'ENamedElement'.
>>
>> Don't do that! That will just get Ed on your case about extending Ecore :-P
>>
>>
>>>
>>> Best,
>>> Marc
>>>
>>> On 2009-02-19 13:36:36 +0100, "Christian W. Damus" <cdamus@zeligsoft.com> said:
>>>
>>>> Hi, Marc,
>>>>
>>>> This is strange. Yes, the OclInvalid results from the
>>>> IllegalArgumentException raised by the interpreter on attempting to
>>>> navigate the 'name' property that doesn't exist.
>>>>
>>>> I'm pretty sure that the problem is in the definition of your Ecore
>>>> model, or the way in which it is loaded. Unless, of course, you are
>>>> parsing the OCL expression in the context of ENamedElement and then
>>>> evaluating it on instances of MyClass? Maybe the non-determinism is in
>>>> the selection of the context for the parsing of the expression ...
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Marc Moser wrote:
>>>>> Hi (I cc'd the OCL newsgroup this time),
>>>>>
>>>>> I (think) I gained a little more insight in the last hours. In
>>>>> particular, I learned the following:
>>>>>
>>>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
>>>>> OCL_INVALID that is returned when evaluation of a query fails. In my
>>>>> case, it fails because it doesn't find the property it looks for.
>>>>>
>>>>> -) In my ecore model, I have a class MyClass, and it has an attribute
>>>>> 'name'. Furthermore I have a subclass MySubClass which extends MyClass.
>>>>> Now, it seems that calling the attribute 'name' was a very bad decision
>>>>> because class ENamedElement has already an attribute called 'name'.
>>>>>
>>>>> -) MyClass does not extend EObject direclty in the model, but of course
>>>>> the generated code will extend EObject...
>>>>>
>>>>> -) Due to some "miracles", I can use eContainer() and all other
>>>>> properties of EObject in my OCL expressions used to specify
>>>>> constraints, derived features and operation bodies.
>>>>>
>>>>> -) Of course I can also use the 'name' property of MySubClass. Now it's
>>>>> getting less funny however, because when evaluating an OCL expression
>>>>> that uses the 'name' property, it will sometimes use the 'name'
>>>>> property of MySubClass, which is correct. But sometimes, it tries to
>>>>> use the 'name' property of ENamedElement, and then it fails because
>>>>> this property does not exist on the model level in MySubClass.
>>>>>
>>>>> I had all these experiences using M4 milestones.
>>>>>
>>>>> Now I'm curious to know:
>>>>>
>>>>> -) why it seems to be random instead of always working or always failing?
>>>>>
>>>>> -) whether making MyClass extend EObject directly in the model is a
>>>>> good solution or if there are better/different ones? Always given that
>>>>> I want to have a 'name' attribute :-)
>>>>>
>>>>> All the best,
>>>>> Marc
>>>>>
>>>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a very strange problem in the application I'm currently
>>>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>>>> Furthermore, I have adapted the EMF templates such that I can use OCL
>>>>>> to specify operation bodies, derived features/attributes and labels
>>>>>> (this redefines the getText() in the EditProviders). In principle,
>>>>>> everything works fine, but I randomly get an IllegalArgumentException
>>>>>> thrown from OCL (see stack trace below). It really seems to be
>>>>>> completely random; I open a resource, it works, I close and reopen it
>>>>>> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
>>>>>> only works 3 out of 10 times I try it.
>>>>>>
>>>>>> Now, the only thing I could figure out was that there seems to be
>>>>>> exactly one class that is not always correctly loaded. Whenever it
>>>>>> works, instances of that class (call it MyClass) are shown with the
>>>>>> correct label in the tree editor. Whenever it doesn't work, instances
>>>>>> of MyClass are displayed as
>>>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>>>>>> MyClass is unknown to the system and some dynamic object is created in
>>>>>> this case. Then, all OCL expressions which use myPackage::myClass (e.g.
>>>>>> accessing features of it) fail with the IllegalArgumentException, which
>>>>>> somehow makes sense because the class seems to be unknown. Thus, it
>>>>>> seems to be more a EMF issue than an OCL problem.
>>>>>>
>>>>>> Does anyone have an idea why my class is "sometimes" not known? It is
>>>>>> also very strange that all the other classes defined in the same (or in
>>>>>> different) packages have no problem at all.
>>>>>>
>>>>>> Or does someone have a hint how I could debug this problem?
>>>>>>
>>>>>> Many thanks!
>>>>>>
>>>>>> Best,
>>>>>> Marc
>>>>>>
>>>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>>>> !STACK 0
>>>>>> java.lang.IllegalArgumentException
>>>>>> at
>>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68099 is a reply to message #68027] |
Fri, 20 February 2009 14:25 |
|
Marc,
Please also note that, if your model extends classes that you can't
re-generate, you can't use generator patterns like reflective
delegation. That would be needed if you plan to use your models with
CDO, as you told me before.
Cheers
/Eike
----
http://thegordian.blogspot.com
Marc Moser schrieb:
> Hi Ed, Christian,
>
> Thanks for your support!
>
> I think the package is loaded correctly. Especially because all other
> classes work well. In principle, all expressions using the 'name'
> attribute fail, all other expressions evaluate well. But I must admit
> I didn't validate the model ._. I'll check this!
>
> The problem finally manifests itself in the operation Object
> navigateProperty(property, qualifiers, target). The target is an
> instance of 'MySubClass', the qualifiers list is empty, but the
> property is not the 'name' attribute of 'MyClass' but the 'name'
> attribute of 'ENamedElement'. Well, it isn't in about half of the
> cases, in the other half the property really is the 'name' attribute
> of 'MyClass'.
>
> I'll have a deeper look later today and try to create an example that
> I can share.
>
> Note also that I "solved" the problem in my case by removing the
> 'name' attribute from 'MyClass' and making 'MyClass' extend
> 'ENamedElement'.
>
> Best,
> Marc
>
> On 2009-02-19 13:36:36 +0100, "Christian W. Damus"
> <cdamus@zeligsoft.com> said:
>
>> Hi, Marc,
>>
>> This is strange. Yes, the OclInvalid results from the
>> IllegalArgumentException raised by the interpreter on attempting to
>> navigate the 'name' property that doesn't exist.
>>
>> I'm pretty sure that the problem is in the definition of your Ecore
>> model, or the way in which it is loaded. Unless, of course, you are
>> parsing the OCL expression in the context of ENamedElement and then
>> evaluating it on instances of MyClass? Maybe the non-determinism is
>> in the selection of the context for the parsing of the expression ...
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Marc Moser wrote:
>>> Hi (I cc'd the OCL newsgroup this time),
>>>
>>> I (think) I gained a little more insight in the last hours. In
>>> particular, I learned the following:
>>>
>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is
>>> actually OCL_INVALID that is returned when evaluation of a query
>>> fails. In my case, it fails because it doesn't find the property it
>>> looks for.
>>>
>>> -) In my ecore model, I have a class MyClass, and it has an
>>> attribute 'name'. Furthermore I have a subclass MySubClass which
>>> extends MyClass. Now, it seems that calling the attribute 'name' was
>>> a very bad decision because class ENamedElement has already an
>>> attribute called 'name'.
>>>
>>> -) MyClass does not extend EObject direclty in the model, but of
>>> course the generated code will extend EObject...
>>>
>>> -) Due to some "miracles", I can use eContainer() and all other
>>> properties of EObject in my OCL expressions used to specify
>>> constraints, derived features and operation bodies.
>>>
>>> -) Of course I can also use the 'name' property of MySubClass. Now
>>> it's getting less funny however, because when evaluating an OCL
>>> expression that uses the 'name' property, it will sometimes use the
>>> 'name' property of MySubClass, which is correct. But sometimes, it
>>> tries to use the 'name' property of ENamedElement, and then it fails
>>> because this property does not exist on the model level in MySubClass.
>>>
>>> I had all these experiences using M4 milestones.
>>>
>>> Now I'm curious to know:
>>>
>>> -) why it seems to be random instead of always working or always
>>> failing?
>>>
>>> -) whether making MyClass extend EObject directly in the model is a
>>> good solution or if there are better/different ones? Always given
>>> that I want to have a 'name' attribute :-)
>>>
>>> All the best,
>>> Marc
>>>
>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>
>>>> Hi,
>>>>
>>>> I have a very strange problem in the application I'm currently
>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>> Furthermore, I have adapted the EMF templates such that I can use
>>>> OCL to specify operation bodies, derived features/attributes and
>>>> labels (this redefines the getText() in the EditProviders). In
>>>> principle, everything works fine, but I randomly get an
>>>> IllegalArgumentException thrown from OCL (see stack trace below).
>>>> It really seems to be completely random; I open a resource, it
>>>> works, I close and reopen it again, it doesn't work... sometimes it
>>>> works 8 out of 10, sometimes it only works 3 out of 10 times I try it.
>>>>
>>>> Now, the only thing I could figure out was that there seems to be
>>>> exactly one class that is not always correctly loaded. Whenever it
>>>> works, instances of that class (call it MyClass) are shown with the
>>>> correct label in the tree editor. Whenever it doesn't work,
>>>> instances of MyClass are displayed as
>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems
>>>> that MyClass is unknown to the system and some dynamic object is
>>>> created in this case. Then, all OCL expressions which use
>>>> myPackage::myClass (e.g. accessing features of it) fail with the
>>>> IllegalArgumentException, which somehow makes sense because the
>>>> class seems to be unknown. Thus, it seems to be more a EMF issue
>>>> than an OCL problem.
>>>>
>>>> Does anyone have an idea why my class is "sometimes" not known? It
>>>> is also very strange that all the other classes defined in the same
>>>> (or in different) packages have no problem at all.
>>>>
>>>> Or does someone have a hint how I could debug this problem?
>>>>
>>>> Many thanks!
>>>>
>>>> Best,
>>>> Marc
>>>>
>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>> !STACK 0
>>>> java.lang.IllegalArgumentException
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>
>
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>> at
>>>>
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>> at
>>>>
>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>
>
>>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>
>>> at
>>>>
>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68115 is a reply to message #68099] |
Fri, 20 February 2009 14:53 |
Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
We do indeed plan to migrate everything to CDO at some point, and I
wasn't aware of this fact.
Thanks for pointing this out!
Best,
Marc
On 2009-02-20 15:25:28 +0100, Eike Stepper <stepper@esc-net.de> said:
> Marc,
>
> Please also note that, if your model extends classes that you can't
> re-generate, you can't use generator patterns like reflective
> delegation. That would be needed if you plan to use your models with
> CDO, as you told me before.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Marc Moser schrieb:
>> Hi Ed, Christian,
>>
>> Thanks for your support!
>>
>> I think the package is loaded correctly. Especially because all other
>> classes work well. In principle, all expressions using the 'name'
>> attribute fail, all other expressions evaluate well. But I must admit I
>> didn't validate the model ._. I'll check this!
>>
>> The problem finally manifests itself in the operation Object
>> navigateProperty(property, qualifiers, target). The target is an
>> instance of 'MySubClass', the qualifiers list is empty, but the
>> property is not the 'name' attribute of 'MyClass' but the 'name'
>> attribute of 'ENamedElement'. Well, it isn't in about half of the
>> cases, in the other half the property really is the 'name' attribute of
>> 'MyClass'.
>>
>> I'll have a deeper look later today and try to create an example that I
>> can share.
>>
>> Note also that I "solved" the problem in my case by removing the 'name'
>> attribute from 'MyClass' and making 'MyClass' extend 'ENamedElement'.
>>
>> Best,
>> Marc
>>
>> On 2009-02-19 13:36:36 +0100, "Christian W. Damus" <cdamus@zeligsoft.com> said:
>>
>>> Hi, Marc,
>>>
>>> This is strange. Yes, the OclInvalid results from the
>>> IllegalArgumentException raised by the interpreter on attempting to
>>> navigate the 'name' property that doesn't exist.
>>>
>>> I'm pretty sure that the problem is in the definition of your Ecore
>>> model, or the way in which it is loaded. Unless, of course, you are
>>> parsing the OCL expression in the context of ENamedElement and then
>>> evaluating it on instances of MyClass? Maybe the non-determinism is in
>>> the selection of the context for the parsing of the expression ...
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Marc Moser wrote:
>>>> Hi (I cc'd the OCL newsgroup this time),
>>>>
>>>> I (think) I gained a little more insight in the last hours. In
>>>> particular, I learned the following:
>>>>
>>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
>>>> OCL_INVALID that is returned when evaluation of a query fails. In my
>>>> case, it fails because it doesn't find the property it looks for.
>>>>
>>>> -) In my ecore model, I have a class MyClass, and it has an attribute
>>>> 'name'. Furthermore I have a subclass MySubClass which extends MyClass.
>>>> Now, it seems that calling the attribute 'name' was a very bad decision
>>>> because class ENamedElement has already an attribute called 'name'.
>>>>
>>>> -) MyClass does not extend EObject direclty in the model, but of course
>>>> the generated code will extend EObject...
>>>>
>>>> -) Due to some "miracles", I can use eContainer() and all other
>>>> properties of EObject in my OCL expressions used to specify
>>>> constraints, derived features and operation bodies.
>>>>
>>>> -) Of course I can also use the 'name' property of MySubClass. Now it's
>>>> getting less funny however, because when evaluating an OCL expression
>>>> that uses the 'name' property, it will sometimes use the 'name'
>>>> property of MySubClass, which is correct. But sometimes, it tries to
>>>> use the 'name' property of ENamedElement, and then it fails because
>>>> this property does not exist on the model level in MySubClass.
>>>>
>>>> I had all these experiences using M4 milestones.
>>>>
>>>> Now I'm curious to know:
>>>>
>>>> -) why it seems to be random instead of always working or always failing?
>>>>
>>>> -) whether making MyClass extend EObject directly in the model is a
>>>> good solution or if there are better/different ones? Always given that
>>>> I want to have a 'name' attribute :-)
>>>>
>>>> All the best,
>>>> Marc
>>>>
>>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a very strange problem in the application I'm currently
>>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>>> Furthermore, I have adapted the EMF templates such that I can use OCL
>>>>> to specify operation bodies, derived features/attributes and labels
>>>>> (this redefines the getText() in the EditProviders). In principle,
>>>>> everything works fine, but I randomly get an IllegalArgumentException
>>>>> thrown from OCL (see stack trace below). It really seems to be
>>>>> completely random; I open a resource, it works, I close and reopen it
>>>>> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
>>>>> only works 3 out of 10 times I try it.
>>>>>
>>>>> Now, the only thing I could figure out was that there seems to be
>>>>> exactly one class that is not always correctly loaded. Whenever it
>>>>> works, instances of that class (call it MyClass) are shown with the
>>>>> correct label in the tree editor. Whenever it doesn't work, instances
>>>>> of MyClass are displayed as
>>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>>>>> MyClass is unknown to the system and some dynamic object is created in
>>>>> this case. Then, all OCL expressions which use myPackage::myClass (e.g.
>>>>> accessing features of it) fail with the IllegalArgumentException, which
>>>>> somehow makes sense because the class seems to be unknown. Thus, it
>>>>> seems to be more a EMF issue than an OCL problem.
>>>>>
>>>>> Does anyone have an idea why my class is "sometimes" not known? It is
>>>>> also very strange that all the other classes defined in the same (or in
>>>>> different) packages have no problem at all.
>>>>>
>>>>> Or does someone have a hint how I could debug this problem?
>>>>>
>>>>> Many thanks!
>>>>>
>>>>> Best,
>>>>> Marc
>>>>>
>>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>>> !STACK 0
>>>>> java.lang.IllegalArgumentException
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68131 is a reply to message #68115] |
Fri, 20 February 2009 15:15 |
|
Marc,
Some more hints that will make it easier for you then. When customizing
your generated code:
- Always use the xyzGen() pattern instead of simply marking a member
@generated NOT.
- Never access the generated fields directly (including framework
fields!). Always use the thenerated getters/setters (possibly te
xyzGen() variants).
- Do not exchange list implementations. If you need to specialize list
behaviour, use a delegating list instead.
- Well, you know this: Do not extend types that you can't re-generate.
If you respect these rules I would bet that your migration is just a
snap ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Marc Moser schrieb:
> We do indeed plan to migrate everything to CDO at some point, and I
> wasn't aware of this fact.
> Thanks for pointing this out!
>
> Best,
> Marc
>
> On 2009-02-20 15:25:28 +0100, Eike Stepper <stepper@esc-net.de> said:
>
>> Marc,
>>
>> Please also note that, if your model extends classes that you can't
>> re-generate, you can't use generator patterns like reflective
>> delegation. That would be needed if you plan to use your models with
>> CDO, as you told me before.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Marc Moser schrieb:
>>> Hi Ed, Christian,
>>>
>>> Thanks for your support!
>>>
>>> I think the package is loaded correctly. Especially because all
>>> other classes work well. In principle, all expressions using the
>>> 'name' attribute fail, all other expressions evaluate well. But I
>>> must admit I didn't validate the model ._. I'll check this!
>>>
>>> The problem finally manifests itself in the operation Object
>>> navigateProperty(property, qualifiers, target). The target is an
>>> instance of 'MySubClass', the qualifiers list is empty, but the
>>> property is not the 'name' attribute of 'MyClass' but the 'name'
>>> attribute of 'ENamedElement'. Well, it isn't in about half of the
>>> cases, in the other half the property really is the 'name' attribute
>>> of 'MyClass'.
>>>
>>> I'll have a deeper look later today and try to create an example
>>> that I can share.
>>>
>>> Note also that I "solved" the problem in my case by removing the
>>> 'name' attribute from 'MyClass' and making 'MyClass' extend
>>> 'ENamedElement'.
>>>
>>> Best,
>>> Marc
>>>
>>> On 2009-02-19 13:36:36 +0100, "Christian W. Damus"
>>> <cdamus@zeligsoft.com> said:
>>>
>>>> Hi, Marc,
>>>>
>>>> This is strange. Yes, the OclInvalid results from the
>>>> IllegalArgumentException raised by the interpreter on attempting to
>>>> navigate the 'name' property that doesn't exist.
>>>>
>>>> I'm pretty sure that the problem is in the definition of your Ecore
>>>> model, or the way in which it is loaded. Unless, of course, you
>>>> are parsing the OCL expression in the context of ENamedElement and
>>>> then evaluating it on instances of MyClass? Maybe the
>>>> non-determinism is in the selection of the context for the parsing
>>>> of the expression ...
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Marc Moser wrote:
>>>>> Hi (I cc'd the OCL newsgroup this time),
>>>>>
>>>>> I (think) I gained a little more insight in the last hours. In
>>>>> particular, I learned the following:
>>>>>
>>>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is
>>>>> actually OCL_INVALID that is returned when evaluation of a query
>>>>> fails. In my case, it fails because it doesn't find the property
>>>>> it looks for.
>>>>>
>>>>> -) In my ecore model, I have a class MyClass, and it has an
>>>>> attribute 'name'. Furthermore I have a subclass MySubClass which
>>>>> extends MyClass. Now, it seems that calling the attribute 'name'
>>>>> was a very bad decision because class ENamedElement has already an
>>>>> attribute called 'name'.
>>>>>
>>>>> -) MyClass does not extend EObject direclty in the model, but of
>>>>> course the generated code will extend EObject...
>>>>>
>>>>> -) Due to some "miracles", I can use eContainer() and all other
>>>>> properties of EObject in my OCL expressions used to specify
>>>>> constraints, derived features and operation bodies.
>>>>>
>>>>> -) Of course I can also use the 'name' property of MySubClass. Now
>>>>> it's getting less funny however, because when evaluating an OCL
>>>>> expression that uses the 'name' property, it will sometimes use
>>>>> the 'name' property of MySubClass, which is correct. But
>>>>> sometimes, it tries to use the 'name' property of ENamedElement,
>>>>> and then it fails because this property does not exist on the
>>>>> model level in MySubClass.
>>>>>
>>>>> I had all these experiences using M4 milestones.
>>>>>
>>>>> Now I'm curious to know:
>>>>>
>>>>> -) why it seems to be random instead of always working or always
>>>>> failing?
>>>>>
>>>>> -) whether making MyClass extend EObject directly in the model is
>>>>> a good solution or if there are better/different ones? Always
>>>>> given that I want to have a 'name' attribute :-)
>>>>>
>>>>> All the best,
>>>>> Marc
>>>>>
>>>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a very strange problem in the application I'm currently
>>>>>> developing. I use EMF/Ecore to model all parts of the
>>>>>> application. Furthermore, I have adapted the EMF templates such
>>>>>> that I can use OCL to specify operation bodies, derived
>>>>>> features/attributes and labels (this redefines the getText() in
>>>>>> the EditProviders). In principle, everything works fine, but I
>>>>>> randomly get an IllegalArgumentException thrown from OCL (see
>>>>>> stack trace below). It really seems to be completely random; I
>>>>>> open a resource, it works, I close and reopen it again, it
>>>>>> doesn't work... sometimes it works 8 out of 10, sometimes it only
>>>>>> works 3 out of 10 times I try it.
>>>>>>
>>>>>> Now, the only thing I could figure out was that there seems to be
>>>>>> exactly one class that is not always correctly loaded. Whenever
>>>>>> it works, instances of that class (call it MyClass) are shown
>>>>>> with the correct label in the tree editor. Whenever it doesn't
>>>>>> work, instances of MyClass are displayed as
>>>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems
>>>>>> that MyClass is unknown to the system and some dynamic object is
>>>>>> created in this case. Then, all OCL expressions which use
>>>>>> myPackage::myClass (e.g. accessing features of it) fail with the
>>>>>> IllegalArgumentException, which somehow makes sense because the
>>>>>> class seems to be unknown. Thus, it seems to be more a EMF issue
>>>>>> than an OCL problem.
>>>>>>
>>>>>> Does anyone have an idea why my class is "sometimes" not known?
>>>>>> It is also very strange that all the other classes defined in the
>>>>>> same (or in different) packages have no problem at all.
>>>>>>
>>>>>> Or does someone have a hint how I could debug this problem?
>>>>>>
>>>>>> Many thanks!
>>>>>>
>>>>>> Best,
>>>>>> Marc
>>>>>>
>>>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>>>> !STACK 0
>>>>>> java.lang.IllegalArgumentException
>>>>>> at
>>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>>>
>
>
>
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>>>
>
>
>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>>>
>
>
>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>>>
>
>
>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>>>
>
>
>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>>>
>
>
>
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>>>
>
>
>
>>>>>>
>>>>> at
>>>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>>>
>>>>> at
>>>>>>
>>>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68170 is a reply to message #68027] |
Fri, 27 February 2009 12:52 |
Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
Hi Christian,
I created a simple example where you can reproduce the problem. It
contains 4 projects (*, *.edit, *.editor and *.test). The *.test
project contains a launch-config and a workspace folder, which contains
a project that you can then import in the runtime-workspace. This
project contains a single resource that you can open with the generated
editor.
When opened, the node should be displayed with the label 'Name: Sample
Container', which in my case happens to be the case in about 40% of all
the cases. In the remaining 60%, it is displayed as
'org.eclipse.emf.ecore.impl.DynamicEO....' which comes from the fact
that evaluating the OCL query returns the OCL invalid constant, because
in the operation 'navigateProperty' it looks for the 'name' attribute
of ENamedElement instead of the 'name' attribute of my class which is
called NamedElement.
Thanks for your help.
All the best,
Marc
> Hi Ed, Christian,
>
> Thanks for your support!
>
> I think the package is loaded correctly. Especially because all other
> classes work well. In principle, all expressions using the 'name'
> attribute fail, all other expressions evaluate well. But I must admit I
> didn't validate the model ._. I'll check this!
>
> The problem finally manifests itself in the operation Object
> navigateProperty(property, qualifiers, target). The target is an
> instance of 'MySubClass', the qualifiers list is empty, but the
> property is not the 'name' attribute of 'MyClass' but the 'name'
> attribute of 'ENamedElement'. Well, it isn't in about half of the
> cases, in the other half the property really is the 'name' attribute of
> 'MyClass'.
>
> I'll have a deeper look later today and try to create an example that I
> can share.
>
> Note also that I "solved" the problem in my case by removing the 'name'
> attribute from 'MyClass' and making 'MyClass' extend 'ENamedElement'.
>
> Best,
> Marc
>
> On 2009-02-19 13:36:36 +0100, "Christian W. Damus" <cdamus@zeligsoft.com> said:
>
>> Hi, Marc,
>>
>> This is strange. Yes, the OclInvalid results from the
>> IllegalArgumentException raised by the interpreter on attempting to
>> navigate the 'name' property that doesn't exist.
>>
>> I'm pretty sure that the problem is in the definition of your Ecore
>> model, or the way in which it is loaded. Unless, of course, you are
>> parsing the OCL expression in the context of ENamedElement and then
>> evaluating it on instances of MyClass? Maybe the non-determinism is in
>> the selection of the context for the parsing of the expression ...
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Marc Moser wrote:
>>> Hi (I cc'd the OCL newsgroup this time),
>>>
>>> I (think) I gained a little more insight in the last hours. In
>>> particular, I learned the following:
>>>
>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is actually
>>> OCL_INVALID that is returned when evaluation of a query fails. In my
>>> case, it fails because it doesn't find the property it looks for.
>>>
>>> -) In my ecore model, I have a class MyClass, and it has an attribute
>>> 'name'. Furthermore I have a subclass MySubClass which extends MyClass.
>>> Now, it seems that calling the attribute 'name' was a very bad decision
>>> because class ENamedElement has already an attribute called 'name'.
>>>
>>> -) MyClass does not extend EObject direclty in the model, but of course
>>> the generated code will extend EObject...
>>>
>>> -) Due to some "miracles", I can use eContainer() and all other
>>> properties of EObject in my OCL expressions used to specify
>>> constraints, derived features and operation bodies.
>>>
>>> -) Of course I can also use the 'name' property of MySubClass. Now it's
>>> getting less funny however, because when evaluating an OCL expression
>>> that uses the 'name' property, it will sometimes use the 'name'
>>> property of MySubClass, which is correct. But sometimes, it tries to
>>> use the 'name' property of ENamedElement, and then it fails because
>>> this property does not exist on the model level in MySubClass.
>>>
>>> I had all these experiences using M4 milestones.
>>>
>>> Now I'm curious to know:
>>>
>>> -) why it seems to be random instead of always working or always failing?
>>>
>>> -) whether making MyClass extend EObject directly in the model is a
>>> good solution or if there are better/different ones? Always given that
>>> I want to have a 'name' attribute :-)
>>>
>>> All the best,
>>> Marc
>>>
>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>
>>>> Hi,
>>>>
>>>> I have a very strange problem in the application I'm currently
>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>> Furthermore, I have adapted the EMF templates such that I can use OCL
>>>> to specify operation bodies, derived features/attributes and labels
>>>> (this redefines the getText() in the EditProviders). In principle,
>>>> everything works fine, but I randomly get an IllegalArgumentException
>>>> thrown from OCL (see stack trace below). It really seems to be
>>>> completely random; I open a resource, it works, I close and reopen it
>>>> again, it doesn't work... sometimes it works 8 out of 10, sometimes it
>>>> only works 3 out of 10 times I try it.
>>>>
>>>> Now, the only thing I could figure out was that there seems to be
>>>> exactly one class that is not always correctly loaded. Whenever it
>>>> works, instances of that class (call it MyClass) are shown with the
>>>> correct label in the tree editor. Whenever it doesn't work, instances
>>>> of MyClass are displayed as
>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems that
>>>> MyClass is unknown to the system and some dynamic object is created in
>>>> this case. Then, all OCL expressions which use myPackage::myClass (e.g.
>>>> accessing features of it) fail with the IllegalArgumentException, which
>>>> somehow makes sense because the class seems to be unknown. Thus, it
>>>> seems to be more a EMF issue than an OCL problem.
>>>>
>>>> Does anyone have an idea why my class is "sometimes" not known? It is
>>>> also very strange that all the other classes defined in the same (or in
>>>> different) packages have no problem at all.
>>>>
>>>> Or does someone have a hint how I could debug this problem?
>>>>
>>>> Many thanks!
>>>>
>>>> Best,
>>>> Marc
>>>>
>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>> !STACK 0
>>>> java.lang.IllegalArgumentException
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>
>>> at
>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>> at
>>>>
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>
>>> at
>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>> at
>>>>
>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>
>>> at
>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>> at
>>>>
>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68267 is a reply to message #68170] |
Fri, 27 February 2009 15:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi Marc,
It's most cool that you were able to assemble a reproducible example.
I'm eager to have a look at it. I hope to get back to you with results
later this afternoon.
cW
Marc Moser wrote:
> Hi Christian,
>
> I created a simple example where you can reproduce the problem. It
> contains 4 projects (*, *.edit, *.editor and *.test). The *.test project
> contains a launch-config and a workspace folder, which contains a
> project that you can then import in the runtime-workspace. This project
> contains a single resource that you can open with the generated editor.
>
> When opened, the node should be displayed with the label 'Name: Sample
> Container', which in my case happens to be the case in about 40% of all
> the cases. In the remaining 60%, it is displayed as
> 'org.eclipse.emf.ecore.impl.DynamicEO....' which comes from the fact
> that evaluating the OCL query returns the OCL invalid constant, because
> in the operation 'navigateProperty' it looks for the 'name' attribute of
> ENamedElement instead of the 'name' attribute of my class which is
> called NamedElement.
>
> Thanks for your help.
>
> All the best,
> Marc
>
>> Hi Ed, Christian,
>>
>> Thanks for your support!
>>
>> I think the package is loaded correctly. Especially because all other
>> classes work well. In principle, all expressions using the 'name'
>> attribute fail, all other expressions evaluate well. But I must admit
>> I didn't validate the model ._. I'll check this!
>>
>> The problem finally manifests itself in the operation Object
>> navigateProperty(property, qualifiers, target). The target is an
>> instance of 'MySubClass', the qualifiers list is empty, but the
>> property is not the 'name' attribute of 'MyClass' but the 'name'
>> attribute of 'ENamedElement'. Well, it isn't in about half of the
>> cases, in the other half the property really is the 'name' attribute
>> of 'MyClass'.
>>
>> I'll have a deeper look later today and try to create an example that
>> I can share.
>>
>> Note also that I "solved" the problem in my case by removing the
>> 'name' attribute from 'MyClass' and making 'MyClass' extend
>> 'ENamedElement'.
>>
>> Best,
>> Marc
>>
>> On 2009-02-19 13:36:36 +0100, "Christian W. Damus"
>> <cdamus@zeligsoft.com> said:
>>
>>> Hi, Marc,
>>>
>>> This is strange. Yes, the OclInvalid results from the
>>> IllegalArgumentException raised by the interpreter on attempting to
>>> navigate the 'name' property that doesn't exist.
>>>
>>> I'm pretty sure that the problem is in the definition of your Ecore
>>> model, or the way in which it is loaded. Unless, of course, you are
>>> parsing the OCL expression in the context of ENamedElement and then
>>> evaluating it on instances of MyClass? Maybe the non-determinism is
>>> in the selection of the context for the parsing of the expression ...
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Marc Moser wrote:
>>>> Hi (I cc'd the OCL newsgroup this time),
>>>>
>>>> I (think) I gained a little more insight in the last hours. In
>>>> particular, I learned the following:
>>>>
>>>> -) The org.eclipse.emf.impl.DynamicEObjectImpl... instance is
>>>> actually OCL_INVALID that is returned when evaluation of a query
>>>> fails. In my case, it fails because it doesn't find the property it
>>>> looks for.
>>>>
>>>> -) In my ecore model, I have a class MyClass, and it has an
>>>> attribute 'name'. Furthermore I have a subclass MySubClass which
>>>> extends MyClass. Now, it seems that calling the attribute 'name' was
>>>> a very bad decision because class ENamedElement has already an
>>>> attribute called 'name'.
>>>>
>>>> -) MyClass does not extend EObject direclty in the model, but of
>>>> course the generated code will extend EObject...
>>>>
>>>> -) Due to some "miracles", I can use eContainer() and all other
>>>> properties of EObject in my OCL expressions used to specify
>>>> constraints, derived features and operation bodies.
>>>>
>>>> -) Of course I can also use the 'name' property of MySubClass. Now
>>>> it's getting less funny however, because when evaluating an OCL
>>>> expression that uses the 'name' property, it will sometimes use the
>>>> 'name' property of MySubClass, which is correct. But sometimes, it
>>>> tries to use the 'name' property of ENamedElement, and then it fails
>>>> because this property does not exist on the model level in MySubClass.
>>>>
>>>> I had all these experiences using M4 milestones.
>>>>
>>>> Now I'm curious to know:
>>>>
>>>> -) why it seems to be random instead of always working or always
>>>> failing?
>>>>
>>>> -) whether making MyClass extend EObject directly in the model is a
>>>> good solution or if there are better/different ones? Always given
>>>> that I want to have a 'name' attribute :-)
>>>>
>>>> All the best,
>>>> Marc
>>>>
>>>> On 2009-02-18 21:13:57 +0100, Marc Moser <moser@montages.com> said:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a very strange problem in the application I'm currently
>>>>> developing. I use EMF/Ecore to model all parts of the application.
>>>>> Furthermore, I have adapted the EMF templates such that I can use
>>>>> OCL to specify operation bodies, derived features/attributes and
>>>>> labels (this redefines the getText() in the EditProviders). In
>>>>> principle, everything works fine, but I randomly get an
>>>>> IllegalArgumentException thrown from OCL (see stack trace below).
>>>>> It really seems to be completely random; I open a resource, it
>>>>> works, I close and reopen it again, it doesn't work... sometimes it
>>>>> works 8 out of 10, sometimes it only works 3 out of 10 times I try it.
>>>>>
>>>>> Now, the only thing I could figure out was that there seems to be
>>>>> exactly one class that is not always correctly loaded. Whenever it
>>>>> works, instances of that class (call it MyClass) are shown with the
>>>>> correct label in the tree editor. Whenever it doesn't work,
>>>>> instances of MyClass are displayed as
>>>>> org.eclipse.emf.impl.DynamicEObjectImpl@.... So it really seems
>>>>> that MyClass is unknown to the system and some dynamic object is
>>>>> created in this case. Then, all OCL expressions which use
>>>>> myPackage::myClass (e.g. accessing features of it) fail with the
>>>>> IllegalArgumentException, which somehow makes sense because the
>>>>> class seems to be unknown. Thus, it seems to be more a EMF issue
>>>>> than an OCL problem.
>>>>>
>>>>> Does anyone have an idea why my class is "sometimes" not known? It
>>>>> is also very strange that all the other classes defined in the same
>>>>> (or in different) packages have no problem at all.
>>>>>
>>>>> Or does someone have a hint how I could debug this problem?
>>>>>
>>>>> Many thanks!
>>>>>
>>>>> Best,
>>>>> Marc
>>>>>
>>>>> !MESSAGE Evaluation failed with an exception: (no message)
>>>>> !STACK 0
>>>>> java.lang.IllegalArgumentException
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:178)
>>>>>
>
>
>
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigatePro perty(EcoreEvaluationEnvironment.java:1)
>>>>
>
>
>
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitPropertyCallExp(EvaluationVisitorImpl.java:1912)
>>>>
>
>
>
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(Proper tyCallExpImpl.java:244)
>>>>
>
>
>
>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitIfExp(EvaluationVisitorImpl.java:1986)
>>>>
>
>
>
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.IfExpImpl.accept(IfExpImpl.java:4 54)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitLetExp(EvaluationVisitorImpl.java:2090)
>>>>>
>
>
>
>>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.impl.LetExpImpl.accept(LetExpImpl.java :362)
>>>> at
>>>>>
>>>>> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(Ab stractEvaluationVisitor.java:223)
>>>>>
>
>
>
>>>>>
>>>> at
>>>> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(Query Impl.java:120)
>>>>
>>>> at
>>>>>
>>>>> org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:66)
>
>
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68278 is a reply to message #68170] |
Fri, 27 February 2009 18:50 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Marc,
I have an answer for you.
The problem is caused by this in code fragment in the ContainerImpl class:
static {
ParsingOptions.setOption(OCL_ENV.getEnvironment(),
ParsingOptions.implicitRootClass(
OCL_ENV.getEnvironment()),
EcorePackage.eINSTANCE.eClass());
}
This sets the "ecore::EPackage" EClass as the implicit root type of your
model. Ordinarily, it only makes sense to specify EObject here, and
then only to access operations like eContainer() and eContents() from
your OCL expressions.
What the ContainerImpl class is doing here is saying that all features
of EPackage, including NamedElement::name which it inherits (as well as,
say, eClassifiers) are applicable to all of your model elements. This
doesn't work without some custom EvaluationEnvironment implementation
that would correctly somehow evaluate access to these features on
non-EPackages at run-time.
So, the result of this is that the Container and other EClasses have two
definitions of "name", one from ecore::EPackage and one from
core::NamedElement. OCL finds both and decides that one must be a
redefinition of the other. An algorithm that uses a HashMap ends up
randomly choosing one of the two "name"s (Ecore doesn't support
redefinition as UML does). This is why the problem only occurs in some
runs and not in others.
I recommend eliminating the implicit root class option, or at least
changing it to EObject if you need access to eContainer() or other
EObject operations.
Cheers,
Christian
Marc Moser wrote:
> Hi Christian,
>
> I created a simple example where you can reproduce the problem. It
> contains 4 projects (*, *.edit, *.editor and *.test). The *.test project
> contains a launch-config and a workspace folder, which contains a
> project that you can then import in the runtime-workspace. This project
> contains a single resource that you can open with the generated editor.
>
> When opened, the node should be displayed with the label 'Name: Sample
> Container', which in my case happens to be the case in about 40% of all
> the cases. In the remaining 60%, it is displayed as
> 'org.eclipse.emf.ecore.impl.DynamicEO....' which comes from the fact
> that evaluating the OCL query returns the OCL invalid constant, because
> in the operation 'navigateProperty' it looks for the 'name' attribute of
> ENamedElement instead of the 'name' attribute of my class which is
> called NamedElement.
>
> Thanks for your help.
>
> All the best,
> Marc
-----8<-----
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68289 is a reply to message #68278] |
Fri, 27 February 2009 19:05 |
Marc Moser
Messages: 66
Registered: July 2009 |
Member |
|
|
Hi Christian,
Thanks a lot for your support!
As you pointed out, we set the implicit root class options because we
need access to EObjects operations; extending EObject in the model
directly is not possible because we consider to move to CDO at some
point, which doesn't allow this extension.
Setting ecore::EPackage EClass as implicit root class is definitely
wrong and I have no clue why I've put it that way.
Many thanks, and sorry for all the trouble this was causing!
All the best,
Marc
On 2009-02-27 19:50:55 +0100, "Christian W. Damus" <cdamus@zeligsoft.com> said:
> Hi, Marc,
>
> I have an answer for you.
>
> The problem is caused by this in code fragment in the ContainerImpl class:
>
> static {
> ParsingOptions.setOption(OCL_ENV.getEnvironment(),
> ParsingOptions.implicitRootClass(
> OCL_ENV.getEnvironment()),
> EcorePackage.eINSTANCE.eClass());
> }
>
> This sets the "ecore::EPackage" EClass as the implicit root type of
> your model. Ordinarily, it only makes sense to specify EObject here,
> and then only to access operations like eContainer() and eContents()
> from your OCL expressions.
>
> What the ContainerImpl class is doing here is saying that all features
> of EPackage, including NamedElement::name which it inherits (as well
> as, say, eClassifiers) are applicable to all of your model elements.
> This doesn't work without some custom EvaluationEnvironment
> implementation that would correctly somehow evaluate access to these
> features on non-EPackages at run-time.
>
> So, the result of this is that the Container and other EClasses have
> two definitions of "name", one from ecore::EPackage and one from
> core::NamedElement. OCL finds both and decides that one must be a
> redefinition of the other. An algorithm that uses a HashMap ends up
> randomly choosing one of the two "name"s (Ecore doesn't support
> redefinition as UML does). This is why the problem only occurs in some
> runs and not in others.
>
> I recommend eliminating the implicit root class option, or at least
> changing it to EObject if you need access to eContainer() or other
> EObject operations.
>
> Cheers,
>
> Christian
>
>
> Marc Moser wrote:
>> Hi Christian,
>>
>> I created a simple example where you can reproduce the problem. It
>> contains 4 projects (*, *.edit, *.editor and *.test). The *.test
>> project contains a launch-config and a workspace folder, which contains
>> a project that you can then import in the runtime-workspace. This
>> project contains a single resource that you can open with the generated
>> editor.
>>
>> When opened, the node should be displayed with the label 'Name: Sample
>> Container', which in my case happens to be the case in about 40% of all
>> the cases. In the remaining 60%, it is displayed as
>> 'org.eclipse.emf.ecore.impl.DynamicEO....' which comes from the fact
>> that evaluating the OCL query returns the OCL invalid constant, because
>> in the operation 'navigateProperty' it looks for the 'name' attribute
>> of ENamedElement instead of the 'name' attribute of my class which is
>> called NamedElement.
>>
>> Thanks for your help.
>>
>> All the best,
>> Marc
>
> -----8<-----
|
|
|
| Re: EClass defined in ecore model not (always) loaded correctly [message #68300 is a reply to message #68289] |
Fri, 27 February 2009 22:35 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Marc,
Don't worry! It was a fun little mystery to unravel. :-) I rather
thought that the EPackage thing must have been unintentional ...
cW
Marc Moser wrote:
> Hi Christian,
>
> Thanks a lot for your support!
>
> As you pointed out, we set the implicit root class options because we
> need access to EObjects operations; extending EObject in the model
> directly is not possible because we consider to move to CDO at some
> point, which doesn't allow this extension.
>
> Setting ecore::EPackage EClass as implicit root class is definitely
> wrong and I have no clue why I've put it that way.
>
> Many thanks, and sorry for all the trouble this was causing!
>
> All the best,
> Marc
>
> On 2009-02-27 19:50:55 +0100, "Christian W. Damus"
> <cdamus@zeligsoft.com> said:
>
>> Hi, Marc,
>>
>> I have an answer for you.
>>
>> The problem is caused by this in code fragment in the ContainerImpl
>> class:
>>
>> static {
>> ParsingOptions.setOption(OCL_ENV.getEnvironment(),
>> ParsingOptions.implicitRootClass(
>> OCL_ENV.getEnvironment()),
>> EcorePackage.eINSTANCE.eClass());
>> }
>>
>> This sets the "ecore::EPackage" EClass as the implicit root type of
>> your model. Ordinarily, it only makes sense to specify EObject here,
>> and then only to access operations like eContainer() and eContents()
>> from your OCL expressions.
>>
>> What the ContainerImpl class is doing here is saying that all features
>> of EPackage, including NamedElement::name which it inherits (as well
>> as, say, eClassifiers) are applicable to all of your model elements.
>> This doesn't work without some custom EvaluationEnvironment
>> implementation that would correctly somehow evaluate access to these
>> features on non-EPackages at run-time.
>>
>> So, the result of this is that the Container and other EClasses have
>> two definitions of "name", one from ecore::EPackage and one from
>> core::NamedElement. OCL finds both and decides that one must be a
>> redefinition of the other. An algorithm that uses a HashMap ends up
>> randomly choosing one of the two "name"s (Ecore doesn't support
>> redefinition as UML does). This is why the problem only occurs in
>> some runs and not in others.
>>
>> I recommend eliminating the implicit root class option, or at least
>> changing it to EObject if you need access to eContainer() or other
>> EObject operations.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Marc Moser wrote:
>>> Hi Christian,
>>>
>>> I created a simple example where you can reproduce the problem. It
>>> contains 4 projects (*, *.edit, *.editor and *.test). The *.test
>>> project contains a launch-config and a workspace folder, which
>>> contains a project that you can then import in the runtime-workspace.
>>> This project contains a single resource that you can open with the
>>> generated editor.
>>>
>>> When opened, the node should be displayed with the label 'Name:
>>> Sample Container', which in my case happens to be the case in about
>>> 40% of all the cases. In the remaining 60%, it is displayed as
>>> 'org.eclipse.emf.ecore.impl.DynamicEO....' which comes from the fact
>>> that evaluating the OCL query returns the OCL invalid constant,
>>> because in the operation 'navigateProperty' it looks for the 'name'
>>> attribute of ENamedElement instead of the 'name' attribute of my
>>> class which is called NamedElement.
>>>
>>> Thanks for your help.
>>>
>>> All the best,
>>> Marc
>>
>> -----8<-----
>
>
|
|
|
Goto Forum:
Current Time: Sun Sep 22 02:47:40 GMT 2024
Powered by FUDForum. Page generated in 0.04975 seconds |
] 
Search
Help
Register
Login
Home
