Description Christian Damus 2006-09-06 16:27:25 EDT

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.