Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » dangling steoretypes after deleted stereotyped elements
dangling steoretypes after deleted stereotyped elements [message #1830319] Thu, 23 July 2020 10:27 Go to next message
Susanne Fuchs is currently offline Susanne FuchsFriend
Messages: 27
Registered: March 2020
Junior Member
Hi,

Since recently, whenever I delete a stereotyped element from my diagram, close Papyrus and later reopen the diagram, I get this message that I have dangling stereotypes for the elements I deleted before.

Can anyone explain this phenomenon?

I have my own architecture context with a static profile. I think that before this happened for the first time, I made some changes in my profile and regenerated the static profile, but I also changed a couple of other things in the .elementtypesconfigurations and architecture context which I don't quite remember.
Could it be that there is something wrong in my .elementtypesconfigurations? Or maybe I did something wrong when I regenerated my static profile?


index.php/fa/38638/0/
Re: dangling steoretypes after deleted stereotyped elements [message #1830324 is a reply to message #1830319] Thu, 23 July 2020 11:10 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Susanne,

This sounds like it could be related to bug 541400.

When you regenerated your profile, did you change its XML namespace? In the debugger, can you trace the reason why the stereotype is not being deleted when its base element is deleted?

Cheers,
Christian
Re: dangling steoretypes after deleted stereotyped elements [message #1831034 is a reply to message #1830324] Mon, 10 August 2020 12:26 Go to previous messageGo to next message
Susanne Fuchs is currently offline Susanne FuchsFriend
Messages: 27
Registered: March 2020
Junior Member
Hi Christian,
you're right, it does look a lot like that bug. I tried to make my palette elementtypesconfigurations,... look like in the commit that fixed it in the bug https://git.eclipse.org/r/c/papyrus/org.eclipse.papyrus-robotml/+/134400/
but sadly it did not change anything about the problem. I'm now trying to find the problem in the debugger. Could you tell where in the code the deleting of stereotypes happens?
Re: dangling steoretypes after deleted stereotyped elements [message #1831082 is a reply to message #1831034] Tue, 11 August 2020 11:26 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

I'd suggest putting a breakpoint in the didRemove(...) method of the ResourceImpl::ContentEList class. Stereotype applications are contained directly in a resource and are the only things likely to be removed from a resource unless you delete a diagram (except in the case of unloading a resource, which removes all its contents).

HTH,
Christian
Re: dangling steoretypes after deleted stereotyped elements [message #1831083 is a reply to message #1831082] Tue, 11 August 2020 11:58 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

This could be a child stealing problem. Usually the problem is that addition of a child to a container automatically removes the child from any previous container (the child is stolen from the old container). I think you might have an elaboration whereby a new child is added to a container displacing the old child that becomes an orphan, normally being taken care of by the garbage collector, but if you retain a reference you can continue using elements of an old model after loading a replacement. (An EMF unload now proxifies many references.)

I find this behavior (it's not a bug, just an unpleasant feature) so insidious that I overload to intercept dangerous addition of a child to a container. Add something like the following to all immediate EObjectImpl derivations,

	@Override
	protected void eBasicSetContainer(InternalEObject newContainer, int newContainerFeatureID) {
		if (newContainer != null) {
			EObject oldContainer = eInternalContainer();
			assert (oldContainer == null) || oldContainer.eIsProxy() || (newContainer == oldContainer) || (oldContainer.eResource() == null);
		}		
		super.eBasicSetContainer(newContainer, newContainerFeatureID);
	}


This is much easier if there is a common Element from everything inherits. I always run with -ea for my tests.

It is then necessary to invoke

	/**
	 * Detach object from its container so that a child-stealing detection is avoided when attaching to a new container.
	 */
	public static void resetContainer(@NonNull EObject eObject) {
		EStructuralFeature eContainingFeature = eObject.eContainingFeature();
		if (eContainingFeature != null) {
			EObject eContainer = eObject.eContainer();
			if (eContainer != null) {
				if (!eContainingFeature.isMany()) {
					eContainer.eSet(eContainingFeature, null);
				}
				else {
					Object objects = eContainer.eGet(eContainingFeature);
					if (objects instanceof List<?>) {
						((List<?>)objects).remove(eObject);
					}
				}
			}
		}
	}


in those very few places where you really do want to replace a contained element. The explicit resetContainer is a useful bit of documentation.

Regards

Ed Willink
Re: dangling steoretypes after deleted stereotyped elements [message #1831136 is a reply to message #1831083] Wed, 12 August 2020 09:31 Go to previous messageGo to next message
Susanne Fuchs is currently offline Susanne FuchsFriend
Messages: 27
Registered: March 2020
Junior Member
Thanks to both of you!

I tried to add the eBasicSetContainer, it did not solve the problem, but maybe I did it wrong, I will try it again later.

In debugging from didRemove(...) I found the following:

First, I realized that I get dangling stereotypes not only for stereotyped elements from my Static Profile and Context, but also when I create an element with a stereotype from a dynamic profile. (I hope I'm using all the terms correctly)

When I have the plug-ins with my architecture context & profile in my workspace, didRemove(...) is not called when I delete an element, and resource is never not null in remove(EObject eObject) in org.eclipse.emf.ecore.util.EcoreUtil

I compared with a workspace WITHOUT these plugins. There, deleting works correctly without the dangling problem. When a stereotyped element is deleted, resource != null for a DynamicEObjectImpl in remove(EObject eObject) in org.eclipse.emf.ecore.util.EcoreUtil
With my plug-ins, doExecuteWithResult(...) in DestroyElementCommand.class is not called at all for a DynamicEObjectImpl when I delete an element from a diagram. doExecuteWithResult(...) is still called for
an OpaqueActionImpl, CSSDecorationNodeImpl, LocationImpl, CSSDecorationNodeImpl,...

I guess this means the DynamicEObject is not deleted? How can I continue with this information?

[Updated on: Wed, 12 August 2020 09:32]

Report message to a moderator

Re: dangling steoretypes after deleted stereotyped elements [message #1831146 is a reply to message #1831136] Wed, 12 August 2020 11:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The eBasicSetContainer override doesn't solve any problem; it just provides a debugging aid to highlight questionable practice.

Since you are using UML (and perhaps Papyrus) models, you would need to inject the eBasicSetContainer code into a private copy of UML (and Papyrus).

Since eBasicSetContainer enables you to diagnose questionable practice that needs a resetContainer call to authenticate it, you are almost guaranteed to have to add a few resetContainer calls to UML / Papyrus to authenticate existing questionable practice before you get to see the one that might be your problem.

If you are not seeing anything yet, then you haven't yet enabled the detection.

Regards

Ed Willink
Re: dangling steoretypes after deleted stereotyped elements [message #1831147 is a reply to message #1831136] Wed, 12 August 2020 11:48 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Susanne Fuchs wrote on Wed, 12 August 2020 05:31
With my plug-ins, doExecuteWithResult(...) in DestroyElementCommand.class is not called at all for a DynamicEObjectImpl when I delete an element from a diagram. doExecuteWithResult(...) is still called for
an OpaqueActionImpl, CSSDecorationNodeImpl, LocationImpl, CSSDecorationNodeImpl,...

I guess this means the DynamicEObject is not deleted? How can I continue with this information?


This is an interesting finding. The StereotypeApplicationAdvice ought to be delegating (indirectly) to the DestroyElementCommand (or some subclass, I suppose) to effect deletion of the applied stereotypes.

Can you debug this advice to see whether it finds stereotype applications to delete and, if not, why not? And if this advice isn't involved in your scenario, then it would be necessary to put a breakpoint in the ElementImpl::eBasicSetContainer method to see what kind of command is actually deleting the element that is leaving the dangling stereotypes behind and trace where that command is coming from, to see why the usual edit-helper advice flow is not happening.

Christian
Re: dangling steoretypes after deleted stereotyped elements [message #1831236 is a reply to message #1831147] Fri, 14 August 2020 14:17 Go to previous message
Susanne Fuchs is currently offline Susanne FuchsFriend
Messages: 27
Registered: March 2020
Junior Member
Hey, thank you very much! I could fix it by deleting extensions to my element types configurations from the plugin.xml. I'm leaving my project today, but I hope others will find this discussion helpful in the future, too!
Previous Topic:table problem
Next Topic:Does Papyrus Require Internet Access
Goto Forum:
  


Current Time: Fri Mar 29 02:10:14 GMT 2024

Powered by FUDForum. Page generated in 0.04158 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top