Bugzilla – Full Text Bug Listing
| Summary: | Element checks for unapplicable stereotypes before the resource assigns a GUID | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Christian Damus <give.a.damus> | ||||
| Component: | Core | Assignee: | Kenn Hussey <Kenn.Hussey> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | Keywords: | performance | ||||
| Version: | 2.0.0 | ||||||
| Target Milestone: | 2.0.1 | ||||||
| Hardware: | Other | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 49539 [details]
Patch that fixes the problem for me
Attached a patch that fixes the eContents containment proxy resolution problem for me in my ID-based resource. I have not tested that this will do the right thing by stereotype applications.
The fix has been committed to CVS. Fixed in M200609071509. Move to verified as per bug 206558. |
The ElementImpl class overrides the two-argument protected eBasicSetContainer() method to call super then check whether any stereotypes that are applied should be unapplied because the new context does not have the correct profile. This happens before the public three-argument eBasicSetContainer() method tells the element's resource that it is attached. If the resource is one that is ID-based (possibly UUID-based), then adding a new element to a UML model causes the following work to be done for nothing: - look for applied stereotypes. This causes the cross-reference adapter to resolve all proxies for the newly added element - the adapter attempts to get the element's fragment from the resource. The resource has not yet assigned an ID, so the default hierarchical-name-based algorithm is applied - the algorithm for computing the fragment traverses resolving eContents() lists - this causes containment proxies to be resolved in my application, loading resources that do not need to be loaded Moreover, the protected eBasicSetContainer() is also called by eContainer() when resolving container proxies. In this case, the structure of the model is not changing so there is no need even to consider that stereotypes may need to be unapplied. I think that if the ElementImpl class overrides the public eBasicSetContainer method, instead, then this problem will not occur.