| Null exception in constraints on EnumerationLiteral [message #11917] |
Sat, 17 March 2007 15:54  |
Eclipse User |
|
|
|
Originally posted by: maiera.de.ibm.com
Hi,
I am trying to define some OCL metaclass constraints on a stereotype
extending the EnumerationLiteral metaclass.
All of them, even the most simple ones, fail with a null exception.
For example:
IRJA0272I Execution of constraint
"CIM::EnumerationLiteral_Constraints::"An EnumerationLiteral must have
public visibility"" failed with an exception: null.
This particular one was:
self.base_EnumerationLiteral.visibility = uml::VisibilityKind::public
Ideas ?
Andy
|
|
|
|
| Null exception in constraints on EnumerationLiteral [message #13558 is a reply to message #13516] |
Sun, 18 March 2007 14:41  |
| Eclipse User |
|
|
|
Originally posted by: maiera.de.ibm.com
Christian,
if I use what you proposed, I get a parsing error: "Unrecognized
variable (packageableElement_visibility)".
Is this way of scoping an attribute documented anywhere ?
But on an even more basic point: Why would the "visibility" attribute be
there multiple times ? In this particular case, it is only inherited
once (EnumerationLiteral has a straight inheritance line, with no
"diamonds" in it). But even if the same metaclass was inherited multiple
times, my understanding of UML2 so far was that any such multiply
inherited metaclasses get "merged" into one single occurrence.
Unless you have further ideas, my take would be a defect...
Andy
Christian W. Damus wrote:
> Hi, Andy,
>
> The only thing that jumps to mind is the problem of the clash between
> the definition of visibility for PackageableElements and for whatever
> other metaclass that EnumerationLiteral inherits it from.
> EnumerationLiterals are PackageableElements by virtue of being
> InstanceSpecifications.
>
> What happens if you try the following?
>
> self.base_EnumerationLiteral.packageableElement_visibility =
> uml::VisibilityKind::public
>
> I'm not quite sure of the name of the name of the other visibility
> property; you'll find it in PackageableElement.java in the UML API.
>
> Christian
>
> Andreas Maier wrote:
>
>> Hi,
>> I am trying to define some OCL metaclass constraints on a stereotype
>> extending the EnumerationLiteral metaclass.
>
>> All of them, even the most simple ones, fail with a null exception.
>
>> For example:
>
>> IRJA0272I Execution of constraint
>> "CIM::EnumerationLiteral_Constraints::"An EnumerationLiteral must have
>> public visibility"" failed with an exception: null.
>
>> This particular one was:
>
>> self.base_EnumerationLiteral.visibility = uml::VisibilityKind::public
>
>> Ideas ?
>
>> Andy
>
|
|
|
| Re: Null exception in constraints on EnumerationLiteral [message #13580 is a reply to message #13558] |
Mon, 19 March 2007 09:15 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andy,
I must have been out to lunch ... I guess I was remembering something from
an older version of the UML API? I don't know ... The problem that I was
recalling was a clash of "visibility" properties that were not duplicated
by diamond inheritance, but actually multiply defined. In any case, it's
irrelevant.
So, it looks like you have a bug.
Cheers,
Christian
Andreas Maier wrote:
> Christian,
> if I use what you proposed, I get a parsing error: "Unrecognized
> variable (packageableElement_visibility)".
>
> Is this way of scoping an attribute documented anywhere ?
>
> But on an even more basic point: Why would the "visibility" attribute be
> there multiple times ? In this particular case, it is only inherited
> once (EnumerationLiteral has a straight inheritance line, with no
> "diamonds" in it). But even if the same metaclass was inherited multiple
> times, my understanding of UML2 so far was that any such multiply
> inherited metaclasses get "merged" into one single occurrence.
>
> Unless you have further ideas, my take would be a defect...
>
> Andy
<snip>
|
|
|
Powered by
FUDForum. Page generated in 0.03821 seconds
Home