Home » Modeling » GMF (Graphical Modeling Framework) » OCL constraint and GMF 2.0 M7
| OCL constraint and GMF 2.0 M7 [message #132031] |
Mon, 04 June 2007 05:35  |
Eclipse User |
|
|
|
Hi !
I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
with OCL link constraints on GMF 2.0.
I use exactly the same model, the same constraint and I set Validation
decorators and Validation Enabled to true, and Validation Provider
priority to medium or high, but I can't link 2 component because my
constraint seems to be raised, even if I have 0 link.
The constraint is this one(always the same ! :p ), and it works only
with GMF 1.0 :
self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
c.name = self.componentModel).maxOutput
If I put a number instead of "ComponentModel.allInstances()->any(c |
c.name = self.componentModel).maxOutput" like that :
self.sourceConnections->size() < 3
the constraint works (on GMF 2.0 and 1.0 )..
Is it a bug, or do I forget something new with GMF 2.0 ?
Greets
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #132254 is a reply to message #132031] |
Mon, 04 June 2007 07:43  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
What is the error message that you get (in the log or elsewhere)? Or do not
get any?
At first blush, I could only suppose that the reference to the
ComponentModel class is not resolved, but that seems unlikely as it is
presumably in the same package as the context class of this constraint (and
it works with GMF 1.0).
We'll need more information to determine whether it is changes in GMF or in
OCL that are at play, here.
Christian
Julien Forot wrote:
> Hi !
>
> I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
> with OCL link constraints on GMF 2.0.
> I use exactly the same model, the same constraint and I set Validation
> decorators and Validation Enabled to true, and Validation Provider
> priority to medium or high, but I can't link 2 component because my
> constraint seems to be raised, even if I have 0 link.
>
> The constraint is this one(always the same ! :p ), and it works only
> with GMF 1.0 :
> self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
> c.name = self.componentModel).maxOutput
>
> If I put a number instead of "ComponentModel.allInstances()->any(c |
> c.name = self.componentModel).maxOutput" like that :
> self.sourceConnections->size() < 3
> the constraint works (on GMF 2.0 and 1.0 )..
>
> Is it a bug, or do I forget something new with GMF 2.0 ?
>
> Greets
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #132355 is a reply to message #132254] |
Mon, 04 June 2007 08:45 |
| Eclipse User |
|
|
|
Hi !
I don't get any error message, there is only the "forbidden arrow" when
I select my connection tool and put the mouse on one of my component..
What kind of other informations would you like ?
Julien
Christian W. Damus a écrit :
> Hi, Julien,
>
> What is the error message that you get (in the log or elsewhere)? Or do not
> get any?
>
> At first blush, I could only suppose that the reference to the
> ComponentModel class is not resolved, but that seems unlikely as it is
> presumably in the same package as the context class of this constraint (and
> it works with GMF 1.0).
>
> We'll need more information to determine whether it is changes in GMF or in
> OCL that are at play, here.
>
> Christian
>
> Julien Forot wrote:
>
>
>>Hi !
>>
>>I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
>>with OCL link constraints on GMF 2.0.
>>I use exactly the same model, the same constraint and I set Validation
>>decorators and Validation Enabled to true, and Validation Provider
>>priority to medium or high, but I can't link 2 component because my
>>constraint seems to be raised, even if I have 0 link.
>>
>>The constraint is this one(always the same ! :p ), and it works only
>>with GMF 1.0 :
>>self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
>>c.name = self.componentModel).maxOutput
>>
>>If I put a number instead of "ComponentModel.allInstances()->any(c |
>>c.name = self.componentModel).maxOutput" like that :
>>self.sourceConnections->size() < 3
>>the constraint works (on GMF 2.0 and 1.0 )..
>>
>>Is it a bug, or do I forget something new with GMF 2.0 ?
>>
>>Greets
>
>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #132367 is a reply to message #132355] |
Mon, 04 June 2007 08:48 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
I would suppose that if the constraint actually didn't parse correctly, or
if evaluation failed at run-time with an exception, then you would see a
message in the workspace log and you wouldn't get the forbidden cursor
(this is just my expectation; I don't know how GMF deals with such
problems)
My guess, then, is that the allInstances() operation is not finding
instances of the ComponentModel class as it did in GMF 1.0.
Are your diagram and model in the same resource? If not, is the scope of
the allInstances() query the model resource or the diagram resource? Or,
does GMF provide an option to customize the scope of allInstances() to
include, for example, the entire resource set?
Cheers,
Christian
Julien Forot wrote:
> Hi !
>
> I don't get any error message, there is only the "forbidden arrow" when
> I select my connection tool and put the mouse on one of my component..
> What kind of other informations would you like ?
>
> Julien
>
> Christian W. Damus a écrit :
>
>> Hi, Julien,
>>
>> What is the error message that you get (in the log or elsewhere)? Or do
>> not get any?
>>
>> At first blush, I could only suppose that the reference to the
>> ComponentModel class is not resolved, but that seems unlikely as it is
>> presumably in the same package as the context class of this constraint
>> (and it works with GMF 1.0).
>>
>> We'll need more information to determine whether it is changes in GMF or
>> in OCL that are at play, here.
>>
>> Christian
>>
>> Julien Forot wrote:
>>
>>
>>>Hi !
>>>
>>>I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
>>>with OCL link constraints on GMF 2.0.
>>>I use exactly the same model, the same constraint and I set Validation
>>>decorators and Validation Enabled to true, and Validation Provider
>>>priority to medium or high, but I can't link 2 component because my
>>>constraint seems to be raised, even if I have 0 link.
>>>
>>>The constraint is this one(always the same ! :p ), and it works only
>>>with GMF 1.0 :
>>>self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
>>>c.name = self.componentModel).maxOutput
>>>
>>>If I put a number instead of "ComponentModel.allInstances()->any(c |
>>>c.name = self.componentModel).maxOutput" like that :
>>>self.sourceConnections->size() < 3
>>>the constraint works (on GMF 2.0 and 1.0 )..
>>>
>>>Is it a bug, or do I forget something new with GMF 2.0 ?
>>>
>>>Greets
>>
>>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #132405 is a reply to message #132367] |
Mon, 04 June 2007 09:29 |
| Eclipse User |
|
|
|
I add me componentModel to the modelResource, during the
createDiagram(..) function in MyEditorDiagramEditorUtil :
ComponentModel ftp = DataModelFactory.eINSTANCE.createComponentModel();
ftp.setName("ftp");
ftp.setMaxInput(3);
ftp.setMaxOutput(3);
modelResource.getContents().add(ftp);
Then I create a componentInstance with componentValue set to "ftp".
I believe that ComponentModel.allInstances() search on the modelResource
(it seems that it was the case on GMF 1.0).. So the ftp model should be
found.. :s
Christian W. Damus a écrit :
> Hi, Julien,
>
> I would suppose that if the constraint actually didn't parse correctly, or
> if evaluation failed at run-time with an exception, then you would see a
> message in the workspace log and you wouldn't get the forbidden cursor
> (this is just my expectation; I don't know how GMF deals with such
> problems)
>
> My guess, then, is that the allInstances() operation is not finding
> instances of the ComponentModel class as it did in GMF 1.0.
>
> Are your diagram and model in the same resource? If not, is the scope of
> the allInstances() query the model resource or the diagram resource? Or,
> does GMF provide an option to customize the scope of allInstances() to
> include, for example, the entire resource set?
>
> Cheers,
>
> Christian
>
>
> Julien Forot wrote:
>
>
>>Hi !
>>
>>I don't get any error message, there is only the "forbidden arrow" when
>>I select my connection tool and put the mouse on one of my component..
>>What kind of other informations would you like ?
>>
>>Julien
>>
>>Christian W. Damus a écrit :
>>
>>
>>>Hi, Julien,
>>>
>>>What is the error message that you get (in the log or elsewhere)? Or do
>>>not get any?
>>>
>>>At first blush, I could only suppose that the reference to the
>>>ComponentModel class is not resolved, but that seems unlikely as it is
>>>presumably in the same package as the context class of this constraint
>>>(and it works with GMF 1.0).
>>>
>>>We'll need more information to determine whether it is changes in GMF or
>>>in OCL that are at play, here.
>>>
>>>Christian
>>>
>>>Julien Forot wrote:
>>>
>>>
>>>
>>>>Hi !
>>>>
>>>>I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
>>>>with OCL link constraints on GMF 2.0.
>>>>I use exactly the same model, the same constraint and I set Validation
>>>>decorators and Validation Enabled to true, and Validation Provider
>>>>priority to medium or high, but I can't link 2 component because my
>>>>constraint seems to be raised, even if I have 0 link.
>>>>
>>>>The constraint is this one(always the same ! :p ), and it works only
>>>>with GMF 1.0 :
>>>>self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
>>>>c.name = self.componentModel).maxOutput
>>>>
>>>>If I put a number instead of "ComponentModel.allInstances()->any(c |
>>>>c.name = self.componentModel).maxOutput" like that :
>>>>self.sourceConnections->size() < 3
>>>>the constraint works (on GMF 2.0 and 1.0 )..
>>>>
>>>>Is it a bug, or do I forget something new with GMF 2.0 ?
>>>>
>>>>Greets
>>>
>>>
>
|
|
| |
| Re: OCL constraint and GMF 2.0 M7 [message #132440 is a reply to message #132367] |
Mon, 04 June 2007 10:09 |
| Eclipse User |
|
|
|
Hi Christian,
Right, GMF adds a message into the workspace log on parsing and evaluation
errors.
As for 'allInstances', LazyExtentMap class is used and initialized with
the contextual
instance passed to the contraint evaluation, so I assume a single resource
scope.
For every constraint evaluation, a new extent map is created to capture
possible
diagram modifications, no sophisticated mechanism involved so far.
From this point of view, I suppose 'allInstances' should work the same way
as in GMF 1.0
Regards,
/Radek
On Mon, 04 Jun 2007 14:48:20 +0200, Christian W. Damus <cdamus@ca.ibm.com>
wrote:
> Hi, Julien,
>
> I would suppose that if the constraint actually didn't parse correctly,
> or
> if evaluation failed at run-time with an exception, then you would see a
> message in the workspace log and you wouldn't get the forbidden cursor
> (this is just my expectation; I don't know how GMF deals with such
> problems)
>
> My guess, then, is that the allInstances() operation is not finding
> instances of the ComponentModel class as it did in GMF 1.0.
>
> Are your diagram and model in the same resource? If not, is the scope of
> the allInstances() query the model resource or the diagram resource? Or,
> does GMF provide an option to customize the scope of allInstances() to
> include, for example, the entire resource set?
>
> Cheers,
>
> Christian
>
>
> Julien Forot wrote:
>
>> Hi !
>>
>> I don't get any error message, there is only the "forbidden arrow" when
>> I select my connection tool and put the mouse on one of my component..
>> What kind of other informations would you like ?
>>
>> Julien
>>
>> Christian W. Damus a écrit :
>>
>>> Hi, Julien,
>>>
>>> What is the error message that you get (in the log or elsewhere)? Or
>>> do
>>> not get any?
>>>
>>> At first blush, I could only suppose that the reference to the
>>> ComponentModel class is not resolved, but that seems unlikely as it is
>>> presumably in the same package as the context class of this constraint
>>> (and it works with GMF 1.0).
>>>
>>> We'll need more information to determine whether it is changes in GMF
>>> or
>>> in OCL that are at play, here.
>>>
>>> Christian
>>>
>>> Julien Forot wrote:
>>>
>>>
>>>> Hi !
>>>>
>>>> I used GMF 1.0 but I wanted to migrate to GMF 2.0. But I have problems
>>>> with OCL link constraints on GMF 2.0.
>>>> I use exactly the same model, the same constraint and I set Validation
>>>> decorators and Validation Enabled to true, and Validation Provider
>>>> priority to medium or high, but I can't link 2 component because my
>>>> constraint seems to be raised, even if I have 0 link.
>>>>
>>>> The constraint is this one(always the same ! :p ), and it works only
>>>> with GMF 1.0 :
>>>> self.sourceConnections->size() < ComponentModel.allInstances()->any(c
>>>> |
>>>> c.name = self.componentModel).maxOutput
>>>>
>>>> If I put a number instead of "ComponentModel.allInstances()->any(c |
>>>> c.name = self.componentModel).maxOutput" like that :
>>>> self.sourceConnections->size() < 3
>>>> the constraint works (on GMF 2.0 and 1.0 )..
>>>>
>>>> Is it a bug, or do I forget something new with GMF 2.0 ?
>>>>
>>>> Greets
>>>
>>>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #132478 is a reply to message #132440] |
Mon, 04 June 2007 11:14 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Thanks for the information. See some replies in-line, below.
Cheers,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Right, GMF adds a message into the workspace log on parsing and evaluation
> errors.
> As for 'allInstances', LazyExtentMap class is used and initialized with
> the contextual
> instance passed to the contraint evaluation, so I assume a single resource
> scope.
Right, and in this case, the resource that contains the contextual instance
would be the model, not the diagram, right? That sounds like it should
work.
> For every constraint evaluation, a new extent map is created to capture
> possible
> diagram modifications, no sophisticated mechanism involved so far.
I guess this might be optimized by caching the extent map until some
resource is modified. Would help the performance of computing the mouse
cursor as it moves about the diagram, during which time no changes would be
expected in any resource ...
> From this point of view, I suppose 'allInstances' should work the same
> way
> as in GMF 1.0
That's right, it should. I'm anxious to hear what Julien sees in debugging
....
> Regards,
> /Radek
>
<snip>
|
|
| | | | | |
| Re: OCL constraint and GMF 2.0 M7 [message #133143 is a reply to message #132970] |
Wed, 06 June 2007 09:22 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
Ah ha! So, the problem is, that the
EvaluationEnvironment::createExtentMap(Object) method is being invoked with
a data value, not an EObject, as the evaluation context. Hence, the empty
map and not a LazyExtentMap.
What is the context element (the "self" instance) of your constraint
evaluation? It should be an EObject, not a data value, to make this work
correctly. The problem for OCL is, that from a data value, there is no way
to determine a resource context, so the extents of EClasses cannot be
determined.
Cheers,
Christian
Julien Forot wrote:
> Hi Christian !
>
> The extentMap variable's Value is Collections$EmptyMap..
>
> Christian W. Damus a écrit :
>> Hi, Julien,
>>
>> Excellent! I see that you are using the evaluation tracing support.
>>
>> This shows that the allInstances() operation is returning null instead of
>> a
>> set. The only way that allInstances() can return null is if the
>> extent-map
>> used in evaluation has a null value for the ComponentModel class. The
>> LazyExtentMap (which is the default implementation) would never have a
>> null value, because it always lazily computes at least an empty set.
>>
>> On the breakpoint that I suggested in the other branch of this thread,
>> see what kind of extent map instance you're dealing with by stepping into
>> the getExtentMap() and get() calls.
>>
>> HTH,
>>
>> Christian
<snip>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #133209 is a reply to message #133143] |
Wed, 06 June 2007 10:11 |
| Eclipse User |
|
|
|
Hi,
Thanks for your help.. I didn't chose explicitely the context of my
constraint, I only create a link constraint on gmfmap.. I believe the
"self" is my "componentInstance" class of ecore, so it should be a
EObject right ? But maybe i'm wrong and it's the componentInstance class
on my DataModel. How can I solve that ? How can I know my context ?
cheers
Christian W. Damus a écrit :
> Hi, Julien,
>
> Ah ha! So, the problem is, that the
> EvaluationEnvironment::createExtentMap(Object) method is being invoked with
> a data value, not an EObject, as the evaluation context. Hence, the empty
> map and not a LazyExtentMap.
>
> What is the context element (the "self" instance) of your constraint
> evaluation? It should be an EObject, not a data value, to make this work
> correctly. The problem for OCL is, that from a data value, there is no way
> to determine a resource context, so the extents of EClasses cannot be
> determined.
>
> Cheers,
>
> Christian
>
>
> Julien Forot wrote:
>
>
>>Hi Christian !
>>
>>The extentMap variable's Value is Collections$EmptyMap..
>>
>>Christian W. Damus a écrit :
>>
>>>Hi, Julien,
>>>
>>>Excellent! I see that you are using the evaluation tracing support.
>>>
>>>This shows that the allInstances() operation is returning null instead of
>>>a
>>>set. The only way that allInstances() can return null is if the
>>>extent-map
>>>used in evaluation has a null value for the ComponentModel class. The
>>>LazyExtentMap (which is the default implementation) would never have a
>>>null value, because it always lazily computes at least an empty set.
>>>
>>>On the breakpoint that I suggested in the other branch of this thread,
>>>see what kind of extent map instance you're dealing with by stepping into
>>>the getExtentMap() and get() calls.
>>>
>>>HTH,
>>>
>>>Christian
>
>
> <snip>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #133359 is a reply to message #133209] |
Wed, 06 June 2007 11:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
Put a breakpoint in the EcoreEvaluationEnvironment::createExtentMap(Object)
method and see what the context object is, that is being passed in. Trace
back through the stack to see why this is being invoked on a non-EObject.
cW
Julien Forot wrote:
> Hi,
> Thanks for your help.. I didn't chose explicitely the context of my
> constraint, I only create a link constraint on gmfmap.. I believe the
> "self" is my "componentInstance" class of ecore, so it should be a
> EObject right ? But maybe i'm wrong and it's the componentInstance class
> on my DataModel. How can I solve that ? How can I know my context ?
>
> cheers
>
> Christian W. Damus a écrit :
>
>> Hi, Julien,
>>
>> Ah ha! So, the problem is, that the
>> EvaluationEnvironment::createExtentMap(Object) method is being invoked
>> with
>> a data value, not an EObject, as the evaluation context. Hence, the
>> empty map and not a LazyExtentMap.
>>
>> What is the context element (the "self" instance) of your constraint
>> evaluation? It should be an EObject, not a data value, to make this work
>> correctly. The problem for OCL is, that from a data value, there is no
>> way to determine a resource context, so the extents of EClasses cannot be
>> determined.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Julien Forot wrote:
>>
>>
>>>Hi Christian !
>>>
>>>The extentMap variable's Value is Collections$EmptyMap..
>>>
>>>Christian W. Damus a écrit :
>>>
>>>>Hi, Julien,
>>>>
>>>>Excellent! I see that you are using the evaluation tracing support.
>>>>
>>>>This shows that the allInstances() operation is returning null instead
>>>>of a
>>>>set. The only way that allInstances() can return null is if the
>>>>extent-map
>>>>used in evaluation has a null value for the ComponentModel class. The
>>>>LazyExtentMap (which is the default implementation) would never have a
>>>>null value, because it always lazily computes at least an empty set.
>>>>
>>>>On the breakpoint that I suggested in the other branch of this thread,
>>>>see what kind of extent map instance you're dealing with by stepping
>>>>into the getExtentMap() and get() calls.
>>>>
>>>>HTH,
>>>>
>>>>Christian
>>
>>
>> <snip>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #133792 is a reply to message #133359] |
Thu, 07 June 2007 09:16 |
| Eclipse User |
|
|
|
Hi ! :)
Well the object value is null on
EcoreEvaluationEnvironment.createExtentMap(Object).
I don't know why..
The context and the extentMap variable are already null during the call
to : QueryImpl.getExtentMap().
But on CimeroEditorOCLFactory, the context is ComponentInstanceImpl.. So
it seems that you are true when you said that my context is a data value
and not an EObject..
On the ConnectionCreateCommand::canExecute(), there is a call to
CimeroEditorBaseItemSemanticEditPolicy.LinkConstraints.canCr eateConnection_3001(getContainer(),
getSource(),getTarget());
But the argument getSource() is a componentInstance, and not an EObject,
and it is used as context later .. So if I understand well, I should an
EObject instead of this ?
Sorry if I'm not very clear..
Cheers
Christian W. Damus a écrit :
> Hi, Julien,
>
> Put a breakpoint in the EcoreEvaluationEnvironment::createExtentMap(Object)
> method and see what the context object is, that is being passed in. Trace
> back through the stack to see why this is being invoked on a non-EObject.
>
> cW
>
> Julien Forot wrote:
>
>
>>Hi,
>>Thanks for your help.. I didn't chose explicitely the context of my
>>constraint, I only create a link constraint on gmfmap.. I believe the
>>"self" is my "componentInstance" class of ecore, so it should be a
>>EObject right ? But maybe i'm wrong and it's the componentInstance class
>>on my DataModel. How can I solve that ? How can I know my context ?
>>
>>cheers
>>
>>Christian W. Damus a écrit :
>>
>>
>>>Hi, Julien,
>>>
>>>Ah ha! So, the problem is, that the
>>>EvaluationEnvironment::createExtentMap(Object) method is being invoked
>>>with
>>>a data value, not an EObject, as the evaluation context. Hence, the
>>>empty map and not a LazyExtentMap.
>>>
>>>What is the context element (the "self" instance) of your constraint
>>>evaluation? It should be an EObject, not a data value, to make this work
>>>correctly. The problem for OCL is, that from a data value, there is no
>>>way to determine a resource context, so the extents of EClasses cannot be
>>>determined.
>>>
>>>Cheers,
>>>
>>>Christian
>>>
>>>
>>>Julien Forot wrote:
>>>
>>>
>>>
>>>>Hi Christian !
>>>>
>>>>The extentMap variable's Value is Collections$EmptyMap..
>>>>
>>>>Christian W. Damus a écrit :
>>>>
>>>>
>>>>>Hi, Julien,
>>>>>
>>>>>Excellent! I see that you are using the evaluation tracing support.
>>>>>
>>>>>This shows that the allInstances() operation is returning null instead
>>>>>of a
>>>>>set. The only way that allInstances() can return null is if the
>>>>>extent-map
>>>>>used in evaluation has a null value for the ComponentModel class. The
>>>>>LazyExtentMap (which is the default implementation) would never have a
>>>>>null value, because it always lazily computes at least an empty set.
>>>>>
>>>>>On the breakpoint that I suggested in the other branch of this thread,
>>>>>see what kind of extent map instance you're dealing with by stepping
>>>>>into the getExtentMap() and get() calls.
>>>>>
>>>>>HTH,
>>>>>
>>>>>Christian
>>>
>>>
>>><snip>
>
>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #133805 is a reply to message #133792] |
Thu, 07 June 2007 09:42 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
That certainly explains it: null is not an instance of EObject or anything
else (unlike in OCL where it *is* an instance of EObject *and everything
else*).
But, componentInstance is most likely an EObject, considering that
ComponentInstanceImpl is modeled in Ecore, right? So the question then is
why it is null, or why null is passed into the constraint evaluation
instead of it. I'm afraid those are GMF issues that I can't help you with;
perhaps Radek can be of assistance, there.
Cheers,
Christian
Julien Forot wrote:
> Hi ! :)
> Well the object value is null on
> EcoreEvaluationEnvironment.createExtentMap(Object).
> I don't know why..
> The context and the extentMap variable are already null during the call
> to : QueryImpl.getExtentMap().
>
> But on CimeroEditorOCLFactory, the context is ComponentInstanceImpl.. So
> it seems that you are true when you said that my context is a data value
> and not an EObject..
>
> On the ConnectionCreateCommand::canExecute(), there is a call to
>
CimeroEditorBaseItemSemanticEditPolicy.LinkConstraints.canCr eateConnection_3001(getContainer(),
> getSource(),getTarget());
>
> But the argument getSource() is a componentInstance, and not an EObject,
> and it is used as context later .. So if I understand well, I should an
> EObject instead of this ?
>
> Sorry if I'm not very clear..
>
> Cheers
>
<snip>
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #133845 is a reply to message #133805] |
Thu, 07 June 2007 10:17 |
| Eclipse User |
|
|
|
One more time thanks a lot for your help !
To summarize :
It seems to me that the context become null on QueryImpl.getExtentMap()
call, cause on CimeroEditorOCLFactory$Expression.initExtentMap(Object),
the context value is ComponentInstanceImpl.
And on QueryImpl<PK,C,O,P,EL,PM,S,COA,SSA,CT,CLS,E>.getExtentMap(), the
context value is null..
Does anyone has an idea ?
cheers
Christian W. Damus a écrit :
> Hi, Julien,
>
> That certainly explains it: null is not an instance of EObject or anything
> else (unlike in OCL where it *is* an instance of EObject *and everything
> else*).
>
> But, componentInstance is most likely an EObject, considering that
> ComponentInstanceImpl is modeled in Ecore, right? So the question then is
> why it is null, or why null is passed into the constraint evaluation
> instead of it. I'm afraid those are GMF issues that I can't help you with;
> perhaps Radek can be of assistance, there.
>
> Cheers,
>
> Christian
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #138670 is a reply to message #133845] |
Fri, 22 June 2007 08:48 |
| Eclipse User |
|
|
|
Nobody can help me ?
Julien Forot a écrit :
> One more time thanks a lot for your help !
> To summarize :
> It seems to me that the context become null on QueryImpl.getExtentMap()
> call, cause on CimeroEditorOCLFactory$Expression.initExtentMap(Object),
> the context value is ComponentInstanceImpl.
> And on QueryImpl<PK,C,O,P,EL,PM,S,COA,SSA,CT,CLS,E>.getExtentMap(), the
> context value is null..
>
> Does anyone has an idea ?
>
> cheers
|
|
|
| Re: OCL constraint and GMF 2.0 M7 [message #139389 is a reply to message #138670] |
Mon, 25 June 2007 17:17 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
I think you'll have to use the debugger to trace the method call stack, to
see where that null value is coming from.
Cheers,
Christian
Julien Forot wrote:
> Nobody can help me ?
>
>
> Julien Forot a écrit :
>
>> One more time thanks a lot for your help !
>> To summarize :
>> It seems to me that the context become null on QueryImpl.getExtentMap()
>> call, cause on CimeroEditorOCLFactory$Expression.initExtentMap(Object),
>> the context value is ComponentInstanceImpl.
>> And on QueryImpl<PK,C,O,P,EL,PM,S,COA,SSA,CT,CLS,E>.getExtentMap(), the
>> context value is null..
>>
>> Does anyone has an idea ?
>>
>> cheers
|
|
| |
| Re: OCL constraint and GMF 2.0 M7 [message #141406 is a reply to message #140954] |
Wed, 04 July 2007 13:56 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Julien,
That DynamicEObjectImpl is likely to be the special OclInvalid token, which
is the OCL's representation of failed evaluations (run-time errors).
So, the right-hand side of the "<" expression is evaluating to OclInvalid.
The only possibility that I see is that the "any" iterator is not finding a
matching value, so that its result is null and accessing the "maxOutput"
attribute of a null value produces OclInvalid.
But, I think this is just a consequence of your original problem, that the
extentMap has no extent-set for the ComponentModel metaclass: the "any"
iterator won't find any matches in a null extent.
Cheers,
Christian
Julien Forot wrote:
> With the version of GMF 2.0 RC4, I get this error :
> Evaluation failed with an exception
> java.lang.ClassCastException:
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl cannot be cast to
> java.lang.Integer
> at java.lang.Integer.compareTo(Unknown Source)
> at
>
org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl.vi sitOperationCallExp(EvaluationVisitorImpl.java:1067)...
>
> That's always the same constraint :
> self.sourceConnections->size() < ComponentModel.allInstances()->any(c |
> c.name = self.componentModel).maxOutput
>
> Maybe it can help little bit more..
|
|
|
Goto Forum:
Current Time: Sun Jul 13 01:42:39 EDT 2025
Powered by FUDForum. Page generated in 0.09592 seconds |
Home