Community
Participate
Working Groups
The actual culprits are ResourceUtil.load(...) and MSLEditingDomain.loadResource(...) methods. They attempt to load resource and if the load method throws an exception, they unload it. On the other hand, the algorithm that determined if the resource is loaded has changed from checking if a root object has been added to checking a flag, changing the timing. Methods ResourceUtil.load(...) and MSLEditingDomain.loadResource(...) are atomic operations: when they return the resource is not loaded so there should not be notification that it is loaded (even though it is followed by the unload notification). This is marked as critical because of the following: 1) This is regression that puts existing code in a bad shape. 2) Most event listeners handling those events are running in either asyncExec, syncExec or UIJob. Depending on which methods they chose they run in different troubles, ranging from wasted processing and memory to bad things in the UI (like multiple dialog boxes in one case).
Created attachment 30650 [details] Patch for the gmf.runtime.emf.core plugin.
Created attachment 30651 [details] Patch for the tests.gmf.runtime.emf.core plugin.
Delivered the M4 fix that will revert the MSL to the old behaviour. The M5 fix will remove the automatic unloading of resources and all listeners will receive both load and unload events for resources that loaded with errors.
Created attachment 35257 [details] Final Patch The final patch is attached to remove all of the auto-unloading and squelching events on resources that failed to load with errors.
The patch has been committed.
[target cleanup] 1.0 M5 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime EMF was the original product and component for this bug