Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315034

Summary: Sample Reflective Ecore Editor does not re-resolve reloaded proxies
Product: [Modeling] EMF Reporter: Ed Willink <ed>
Component: CoreAssignee: Ed Merks <Ed.Merks>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3    
Version: 1.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard:

Description Ed Willink CLA 2010-05-31 03:39:16 EDT 
The following problem showed up while preparing a tutorial on the OCL delegate functionality, but is not really an OCL problem.

While using the Sample Reflective Ecore Editor to edit a dynamic XMI model, the Ecore meta-model was changed to enhance a validation constraint. Invoking Validate then gives an NPE in OCLDelegateDomain because the EPackage has no eResource; the EClass is a proxy.

When the meta-model is changed, EcoreEditor.handleChangedResources (in response to handleActivate) invokes eSetProxyURI to trash the meta-model, but the model instance continues to use those proxies as its meta-model.

This was not previously a serious problem because the proxy meta-model did not cause obvious problems, although it perhaps contributed to my wariness of two Ecore Editors with a ResourceSet overlap.

The scenario of a changing meta-model is important to OCL users who may be developing their OCL constraints and exercising them on the loaded model.

Is there an easy way for EcoreEditor.handleChangesResources or ValidateAction to fix up the proxies? My quick experiments with EcoreUtil.resolveAll suggest that the underlying EcoreUtil.resolveCrossReferences was not intended to resolve dynamic meta-model proxies.
Comment 1 Ed Merks CLA 2010-05-31 08:54:24 EDT 
No, editing a model for which instances exist isn't supported.  The model could change arbitrarily in ways that invalidate the instance.
Comment 2 Ed Willink CLA 2010-05-31 11:01:55 EDT 
Yes, clearly for an arbitrary meta-model change the model cannot survive.

But 1: there is a significant use case in which the meta-model change is compatible where it is unkind to require the user to close and re-open the editor. It would be nice, perhaps to offer a do you want to reload prompter, that may then fail dreadfully during reload just as an independent reload would fail.

But 2: the Sample Reflective Ecore Editor continues after a meta-model change having reloaded the meta-model. A wide variety of nasty NPEs, CCEs, IAEs, happen to the ongoing usage, many of them are in the OCL validation, but some are in EMF alone. If reloading the meta-model was invalid, it should not have been reloaded.
Comment 3 Ed Merks CLA 2010-05-31 15:08:19 EDT 
Things like EObject.eClass() would need to resolve EClass proxies, but I don't want to add such code for all clients.  The new EClass could be totally different, so any type of failure is possible anyway.  I don't see a good way to make this robust, nor do I have the time. Contributions that don't impact the core runtime would be interesting to see.
Comment 4 Ed Willink CLA 2010-05-31 15:23:37 EDT 
Agree; it definitely should impact core run-time.

I'm thinking in terms of a refreshMetaModel facility that could be invoked from EcoreEditor.handleChangedResources.

It would
a) resolve all eClass proxies
b) diagnose incompatibilities with the features

and perhaps one day
c) offer an opportunity to delete/rename offending elements