|
Re: Problems with OCL validation and derived properties [message #1827283 is a reply to message #1827281] |
Tue, 12 May 2020 09:13 |
Ed Willink Messages: 7661 Registered: July 2009 |
Senior Member |
|
|
Hi
Getting into trouble in EMF's InternalSettingDelegate usually means that the test that diverted the control flow to OCL has failed and some unsatisfactory EMF fallback has taken over.
The failing line is:
Object setting = settings.dynamicGet(index);
so settings must have been computed as null in StateImpl.eIsSet
Glancing at the ecore, initial appears to have a lower bound of 1, so it is guaranteed to be non-null. However the EMF default is null, so the OCL won't null-check it, which might explain the NPE.
If you need further help please identify a JUnit test or main() to run and create the stack trace.
Regards
Ed Willink
[Updated on: Tue, 12 May 2020 09:15] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Problems with OCL validation and derived properties [message #1827373 is a reply to message #1827327] |
Wed, 13 May 2020 19:31 |
Andrzej Wąsowski Messages: 21 Registered: November 2019 |
Junior Member |
|
|
I just did two things:
* switch the OCL from machine.initial = self to self = machine.initial. This seems to have no impact on the result. Strange?
* I then tried to make a minimal test case for you, but when I got (almost) there, I realized that the test started to pass. So I changed something that has an effect. And it seems to be related to the fixture code loading some other model files. Perhaps I do not understand what validation does; apparently some other models loaded, influence the validation of my model in questions (these other instances may indeed violate the lowerbound constraint). I am puzzled why. This will require more attention - while preparing a case for you, I might solve the problem :P. I shall retry tomorrow.
[Updated on: Wed, 13 May 2020 19:35] Report message to a moderator
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04986 seconds