Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 339904 - When using Graphiti, calling eGet throws IllegalStateException because of Bpmn2OppositeReferenceAdapter
Summary: When using Graphiti, calling eGet throws IllegalStateException because of Bpm...
Status: RESOLVED FIXED
Alias: None
Product: MDT.BPMN2
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-14 11:14 EDT by Ivar Meikas CLA
Modified: 2011-03-18 02:29 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ivar Meikas CLA 2011-03-14 11:14:16 EDT 
Build Identifier: 

While using Graphiti I try to get incomingConversationLinks from Participant using eGet and I get a IllegalStateException.

This happens because Graphiti adds TransactionChangeRecorder as one of the adapters that need notification and Bpmn2OppositeReferenceAdapter uses internally EObjectEList for returning opposite objects.  If Bpmn2OppositeReferenceAdapter would use regular List instead of EObjectEList, this wouldn't happen. Is the EObjectEList necessary ?

Exception I get:
java.lang.IllegalStateException: Cannot modify resource set without a write transaction
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:348)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.appendNotification(TransactionChangeRecorder.java:302)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.processObjectNotification(TransactionChangeRecorder.java:284)
	at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.notifyChanged(TransactionChangeRecorder.java:240)
	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380)
	at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(EcoreEList.java:255)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:310)
	at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307)
	at org.eclipse.bpmn2.util.Bpmn2OppositeReferenceAdapter.getOppositeList(Bpmn2OppositeReferenceAdapter.java:105)
	at org.eclipse.bpmn2.impl.ParticipantImpl.getIncomingConversationLinks(ParticipantImpl.java:144)
	at org.eclipse.bpmn2.impl.ParticipantImpl.eGet(ParticipantImpl.java:334)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)

Reproducible: Always
Comment 1 Henning Heitkoetter CLA 2011-03-16 11:43:42 EDT 
As I understand it, EMF (for example the generated editor) expects values of multi-valued features to implement InternalEList (see Javadoc of that interface). Thus, some list type provided by EMF is needed, but not necessarily a notifying one. I will look for a suitable replacement.

One question remains however: the feature incomingConversationLinks is marked as derived + transient. Why does the transaction mechanism not allow modifications like the one happening here (on-the-fly creation of list), although they do not modify the resource set?
Seem's odd to me, but nevermind - notification is not needed and moreover most likely not wanted here.
Comment 2 Henning Heitkoetter CLA 2011-03-16 12:18:01 EDT 
Fixed with commit e452f4a7f3b8be78047841ce4d101baa4a26d877 (return BasicInternalEList)
Comment 3 Ahti Kitsik CLA 2011-03-18 02:29:24 EDT 
Awesome, works, thanks!