This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In my "MOF compiler" I link references to their associations using 'reference.refSetValue("referencedEnd", referencedEnd)'. This works correctly, and I can see in MDR Explorer that MOF is calculating the derived "exposedEnd" of the reference correctly. And furthermore, my code works correctly when navigating from the reference to the association (using "reference.getReferencedEnd()"). So, it seems that the Exposes association is getting derived correctly. After building the model, I am using the refVerifyConstraints(false) method to verify that the metamodel is valid, after parsing and building the metamodel. I do this by using looping through all ModelElement instances (extent.getModelElement().refAllOfType().iterator()), calling refVerifyConstraints on each one. refVerifyConstraints doesn't report any errors, except exactly one error for each reference. The error is, javax.jmi.reflect.WrongSizeException: Not enough objects linked to 5F439E8F-9961-11D6-AAB2-42F1356CAA77:0000000000001017 at end 'referrer'. Since my built model seems to be valid from inspection of my code, and using MDR Explorer, my hypothesis is that refVerifyConstraints() is using some shortcut that bypasses the calculation of the Exposes assocation. I am guessing that this is the case for all derived associations. As a result, MDR of not seeing the calculated links, it will always report false underflows for derived assocations (or at least for "Exposes" in the MOF metamodel). I will try to build a testcase or a patch to fix the problem, depending on which one I can finish first.
refVerifyConstraints delegates to _verify(), which delegates everything to the storage delegate. The storage delegate then uses its indexes to do the validation. But, I'm guessing that the storage delegate for derived associations doesn't know anything about the derived values. So, the code likely needs to either (a) move all the verification to the instance handlers, or (b) implement two code paths, one for derived attributes/associations and one for non-derivied attributes/associations. Option (b) will only work if instance handlers are forever restricted from calculating values of elements with isDerived=false independently of the storage, and/or if there is some way for MDR to detect that the storage cannot verify the constraint. Presumably, a similar problem will arise when the verification of modeled constraints is implemented, since the storage delegate won't know how to verify them.
Thanks Brian for catching this. I am working on fixing it.
Hi Brian, I have fixed this by not checking constraints on derived elements. We will enable checking constraints of them after enabling modeled constraints checking (there are more problems with derived elements such as immediate upper multiplicity checking which requires immediate computation of derived value, etc. - we need to think about it more...)
I verified that the error is no longer reported in my application. Thank you.