Community
Participate
Working Groups
The assumption that all EObjects are model elements (either UML elements, stereotype instances, diagram views, table instances, etc.) is invalid in a CDO context because CDO resources are EObjects. So, a more accurate determination of what is a model element is that it is an EObject that is not also a Resource. To that end, Papyrus code that tests whether objects are EObjects needs to be reviews to see whether it should be more discriminating. This should be supported by new utilities that abstract the notion (possibly with extensibility) of what constitutes a "model element".
I'll take this on (work already in progress).
Committed in r9980: Added EMFHelper utilities: * boolean isEMFModelElement(Object) - is an object an EMF model element? * EObject asEMFModelElement(Object) - coerce an object to an EMF model element, if appropriate These utilities currently check only that the object is an EObject and that it is not a Resource. This excludes CDOResources. Also, the existing EObject getEObject(Object) API is updated to filter on the "is model element" condition. This fixes numerous exceptions and other problems in the UI, where for example the calculation of menu enablement bombs on attempts to work with the eResource of an EObject (which for a CDOResource doesn't make sense). These new utilities are employed in listeners that manipulate and/or clean up stereotype applications, as they would react to changes in CDOResources at inopportune times (e.g., trying to get the eContainer() or eResource() of a CDOResource that has been unloaded when a transaction is closed, which then fails because the CDOResource is a dead object after the transaction has been closed).
The known problem use cases have been addressed. Any further issues will have to be raised as bugs as they are discovered.
