|
| Re: OCL rules processing classes on different packages [message #62549 is a reply to message #62525] |
Mon, 29 September 2008 14:17   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Samuel,
The OclInvalid usually indicates some kind of RuntimeException in the
evaluation, like a ClassCastException, IllegalArgumentException, or
NullPointerException. Can you debug to find out which exception is
being thrown, where?
I don't have any ideas off-hand ... If you can provide a small
reproducible test case, you could attach it to a bug so we can
investigate the problem, in case it's a bug in the OCL interpreter.
Cheers,
Christian
samuel wrote:
> Hi all !
>
> I have some problem with a rule processing classes on a different
> package thant the context.
> I have an OCL method taking a parameter of a type defined in another emf
> package (dreams.model). This parameter was unkonw at the compilation, so
> I prefixed this parameter type by model:: and the compilation was ok.
> But during the execution, when accessing to this parameter, I have an
> OCLInvalid error (with ocl verbose). If the parameter type is in the
> same package, I have no problem.
>
> Any idea ?
>
> Here is my OCL :
> ------------------------------------------------------------ ------------------
>
> package dreams
>
> context ResourceExtendedTest
> def rankResource : rankResource(req :
> model::RequiredResource):Real=(
>
> if (req.duration > 0) then
> 100.0 else -0.0
> endif
> )
> endpackage
> ------------------------------------------------------------ ------------------
>
>
> Thanks in advance,
>
> Samuel
>
|
|
|
|
| Re: OCL rules processing classes on different packages [message #62595 is a reply to message #62571] |
Wed, 01 October 2008 13:00 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Great! I'm glad you were able to resolve the problem.
Perhaps a little more diagnostic information from the interpreter would
have been useful to you.
Christian
samuel wrote:
> Thanks you for your answer.
>
> I debugged the ocl execution, and it was our bug. The eClass of the
> parameter was not the same instance (same object, but different adress)
> than the eCLass loaded in the OCL evaluator. And somewhere, there was a
> containsAll on the eClass properties returning false, launching the
> OCLIsInvalid error.
>
> It's working now, thanks for your help !
>
|
|
|
Powered by
FUDForum. Page generated in 0.02988 seconds
] 
Search
Help
Register
Login
Home
