Bug 455580 - incorrect stereotype application resolution with some xml load options
Summary: incorrect stereotype application resolution with some xml load options
Status: NEW
Alias: None
Product: MDT.UML2
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows NT
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: UML2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-18 04:31 EST by Laurent Goubet CLA
Modified: 2015-02-25 09:23 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Goubet CLA 2014-12-18 04:31:13 EST
The unit test for this is too hard to create... but in short, I've ended up with the following returning "null" :

umlClass.getStereotypeApplication(umlClass.getAppliedStereotypes().get(0));

or

umlClass.getAppliedStereotypes().get(0); // returns "stereotype1"
umlClass.geStereotypeApplications(); // empty list

Which seems extremely wrong.

The problem being that "ElementImpl#getStereotypeApplications()" is called _during the loading_ of my model, at a moment where the profile is not yet loaded, and thus an empty list is setup in the CacheAdapter. This empty list is then never cleared for subsequent calls to getStereotypeApplications() (If I place a debug point inside this method and explicitely clear the CacheAdapter during invocation, it will properly "find" the stereotype applications, i.e. it only needs to search for it to see that the empty list is erroneous).

This happens when loading a model on which a static profile has been applied with the following two load options :

- XMLResource.OPTION_DEFER_ATTACHMENT
- XMLResource.OPTION_DISABLE_NOTIFY

using either option individually won't cause the issue, only when using both of them at once. This may be minor, but it is _extremely_ hard to debug and there should at the very least be a mention somewhere in the documentation or code that these options should never be used with UML (see also bug 455572 for another example of UML2 inccorectly handling the load options).

I couldn't create a test case easily for this, but we saw this failure with test https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.uml2.ide.tests/src/org/eclipse/emf/compare/uml2/ide/tests/profile/ProfileLoadingTest.java#n174 (loadStaticProfile) which tries and load the following UML model : https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.uml2.ide.tests/src/org/eclipse/emf/compare/uml2/ide/tests/profile/data/loading/static_/model.uml on which this profile is applied : https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.uml2.tests/model/uml2.compare.testprofile.profile.uml .

I guess extracting the profile in another plugin would allow us to reproduce, but I am not familiar enough with exactly "what" this profile is (generated code, uml/genmodel files...) to do that.
Comment 1 Kenn Hussey CLA 2014-12-22 09:47:19 EST
(In reply to Laurent Goubet from comment #0)
> The problem being that "ElementImpl#getStereotypeApplications()" is called
> _during the loading_ of my model, at a moment where the profile is not yet
> loaded, and thus an empty list is setup in the CacheAdapter. This empty list
> is then never cleared for subsequent calls to getStereotypeApplications()
> (If I place a debug point inside this method and explicitely clear the
> CacheAdapter during invocation, it will properly "find" the stereotype
> applications, i.e. it only needs to search for it to see that the empty list
> is erroneous).

Can you indicate where/how this is being called while the reousrce is being loaded? I suppose one way to fix this would be to clear the cache adapter just before notifications are turned back on after the resource has been loaded…
Comment 2 Kenn Hussey CLA 2015-02-25 09:23:05 EST
Without a test case it’s hard for me to reproduce this, but I could imagine that changing the ElementImpl#eSetDeliver(boolean) method to something like the following would do the trick:


	@Override
	public void eSetDeliver(boolean deliver) {

		if (deliver) {
			CacheAdapter cacheAdapter = getCacheAdapter();

			if (cacheAdapter != null) {
				cacheAdapter.clear(this.eResource());
				cacheAdapter.handleCrossReference(this);
			}
		}

		super.eSetDeliver(deliver);
	}

Are you able to try this out in your environment to confirm?