Home » Modeling » EMF » Exception while Undoing a reference (with Opposite) change in a AbstractEMFOpera
| Exception while Undoing a reference (with Opposite) change in a AbstractEMFOpera [message #414323] |
Wed, 31 October 2007 09:32  |
Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
Hi,
My model looks like that : I have 2 classes that reference each other
("opposite" )with a 1-many relationship:
A.myBList
B.myA
The problem is, when I do a a1.getmyBList().add(b1) and I undo this,
everything is fine.
But, when I do a b1.setmyA(b1) and I undo this, I get
BasicEList$BasicIndexOutOfBoundsException (see stack at the end)
The thing seems to be that, when recording changes, the Transaction is
notified and record 2 changes (in both cases) and try then to undo 2
sub-operations.
In the first case, it seems to work by chance whereas in second case, the
elements seems to be tried to be removed twice.
The problem may not occur if one of the reference is derived (because
BasicChangeRecorder.shouldRecord then returns false).
Is it a bug or is it mandatory to have one end of a bidirectionnal
relationship derived?
Thx
Exception:
org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBounds Exception:
index=2, size=2
at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:5 35)
at
org.eclipse.emf.ecore.change.impl.ListChangeImpl.applyAndRev erse(ListChangeImpl.java:535)
at
org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.preA pply(ChangeDescriptionImpl.java:474)
at
org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl yAndReverse(ChangeDescriptionImpl.java:321)
at
org.eclipse.emf.transaction.util.CompositeChangeDescription. applyAndReverse(CompositeChangeDescription.java:105)
at
org.eclipse.emf.workspace.AbstractEMFOperation.doUndo(Abstra ctEMFOperation.java:525)
at
org.eclipse.gmf.runtime.emf.commands.core.command.AbstractTr ansactionalCommand.doUndo(AbstractTransactionalCommand.java: 259)
at
org.eclipse.emf.workspace.AbstractEMFOperation.undo(Abstract EMFOperation.java:306)
at
org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCo mmand.doUndoWithResult(SemanticCreateCommand.java:102)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. undo(AbstractCommand.java:215)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doUndoWithResult(CompositeCommand.java:625)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. undo(AbstractCommand.java:215)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doUndoWithResult(CompositeCommand.java:625)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. undo(AbstractCommand.java:215)
at
org.eclipse.emf.workspace.CompositeEMFOperation.doUndo(Compo siteEMFOperation.java:364)
at
org.eclipse.emf.workspace.AbstractEMFOperation.undo(Abstract EMFOperation.java:306)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doUndoWithResult(CompositeCommand.java:625)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. undo(AbstractCommand.java:215)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doUndoWithResult(CompositeCommand.java:625)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. undo(AbstractCommand.java:215)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .doUndo(DefaultOperationHistory.java:415)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .undo(DefaultOperationHistory.java:1268)
at
org.eclipse.ui.operations.UndoActionHandler.runCommand(UndoA ctionHandler.java:78)
at
org.eclipse.ui.operations.OperationHistoryActionHandler$4.ru n(OperationHistoryActionHandler.java:314)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:369)
|
|
|
| Re: Exception while Undoing a reference (with Opposite) change in a AbstractEMFOpera [message #414324 is a reply to message #414323] |
Wed, 31 October 2007 12:02  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Mat,
As far as I know, the ChangeRecorder is intended to handle mutation of a
bidrectional 1-to-many reference from either end. The only problems that I
have seen are in metamodels that have internal side-effects, such as MDT
UML2's superset-subset feature synchronization.
In any case, you absolutely should not be required to make either end of
this reference derived. That wouldn't make sense.
I suspect that something more is going on, here. Can you raise a bugzilla
with a reproducible test case attached? (preferably a JUnit test) Then I
can have a look to see where the problem lies.
Thanks,
Christian
Mat Lo wrote:
> Hi,
>
> My model looks like that : I have 2 classes that reference each other
> ("opposite" )with a 1-many relationship:
> A.myBList
> B.myA
>
> The problem is, when I do a a1.getmyBList().add(b1) and I undo this,
> everything is fine.
> But, when I do a b1.setmyA(b1) and I undo this, I get
> BasicEList$BasicIndexOutOfBoundsException (see stack at the end)
>
> The thing seems to be that, when recording changes, the Transaction is
> notified and record 2 changes (in both cases) and try then to undo 2
> sub-operations.
> In the first case, it seems to work by chance whereas in second case, the
> elements seems to be tried to be removed twice.
>
> The problem may not occur if one of the reference is derived (because
> BasicChangeRecorder.shouldRecord then returns false).
>
> Is it a bug or is it mandatory to have one end of a bidirectionnal
> relationship derived?
>
> Thx
-----8<-----
|
|
|
| Re: Exception while Undoing a reference (with Opposite) change in a AbstractEMFOpera [message #414327 is a reply to message #414324] |
Wed, 31 October 2007 12:21 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010905000206050802020301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
There have certainly been a few bugs in the case of handling
bidirectional references so that makes me wonder which version Mat is
using. Definitely a test case is needed. We have quite a few tests in
ChangeRecorderTest.java already, so I'm pretty sure this case should be
working properly in EMF 2.3.
Christian W. Damus wrote:
> Hi, Mat,
>
> As far as I know, the ChangeRecorder is intended to handle mutation of a
> bidrectional 1-to-many reference from either end. The only problems that I
> have seen are in metamodels that have internal side-effects, such as MDT
> UML2's superset-subset feature synchronization.
>
> In any case, you absolutely should not be required to make either end of
> this reference derived. That wouldn't make sense.
>
> I suspect that something more is going on, here. Can you raise a bugzilla
> with a reproducible test case attached? (preferably a JUnit test) Then I
> can have a look to see where the problem lies.
>
> Thanks,
>
> Christian
>
>
> Mat Lo wrote:
>
>
>> Hi,
>>
>> My model looks like that : I have 2 classes that reference each other
>> ("opposite" )with a 1-many relationship:
>> A.myBList
>> B.myA
>>
>> The problem is, when I do a a1.getmyBList().add(b1) and I undo this,
>> everything is fine.
>> But, when I do a b1.setmyA(b1) and I undo this, I get
>> BasicEList$BasicIndexOutOfBoundsException (see stack at the end)
>>
>> The thing seems to be that, when recording changes, the Transaction is
>> notified and record 2 changes (in both cases) and try then to undo 2
>> sub-operations.
>> In the first case, it seems to work by chance whereas in second case, the
>> elements seems to be tried to be removed twice.
>>
>> The problem may not occur if one of the reference is derived (because
>> BasicChangeRecorder.shouldRecord then returns false).
>>
>> Is it a bug or is it mandatory to have one end of a bidirectionnal
>> relationship derived?
>>
>> Thx
>>
>
> -----8<-----
>
--------------010905000206050802020301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
There have certainly been a few bugs in the case of handling
bidirectional references so that makes me wonder which version Mat is
using. Definitely a test case is needed. We have quite a few tests in
ChangeRecorderTest.java already, so I'm pretty sure this case should be
working properly in EMF 2.3.<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:fg9qti$ou9$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Mat,
As far as I know, the ChangeRecorder is intended to handle mutation of a
bidrectional 1-to-many reference from either end. The only problems that I
have seen are in metamodels that have internal side-effects, such as MDT
UML2's superset-subset feature synchronization.
In any case, you absolutely should not be required to make either end of
this reference derived. That wouldn't make sense.
I suspect that something more is going on, here. Can you raise a bugzilla
with a reproducible test case attached? (preferably a JUnit test) Then I
can have a look to see where the problem lies.
Thanks,
Christian
Mat Lo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
My model looks like that : I have 2 classes that reference each other
("opposite" )with a 1-many relationship:
A.myBList
B.myA
The problem is, when I do a a1.getmyBList().add(b1) and I undo this,
everything is fine.
But, when I do a b1.setmyA(b1) and I undo this, I get
BasicEList$BasicIndexOutOfBoundsException (see stack at the end)
The thing seems to be that, when recording changes, the Transaction is
notified and record 2 changes (in both cases) and try then to undo 2
sub-operations.
In the first case, it seems to work by chance whereas in second case, the
elements seems to be tried to be removed twice.
The problem may not occur if one of the reference is derived (because
BasicChangeRecorder.shouldRecord then returns false).
Is it a bug or is it mandatory to have one end of a bidirectionnal
relationship derived?
Thx
</pre>
</blockquote>
<pre wrap=""><!---->
-----8<-----
</pre>
</blockquote>
<br>
</body>
</html>
--------------010905000206050802020301--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Exception while Undoing a reference (with Opposite) change in a AbstractEMFO [message #414329 is a reply to message #414327] |
Wed, 31 October 2007 13:28 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
Hi again.
Thx for your answers.
Actually, I'm using EMF 2.3 (some plugins under 2.3.0.v200708301145 and
some others 2.3.1.v200708301145).
A similar (but not quite the same) bug I found is :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150866
It seems to be fixed since 2.2.1.
I'll work on a test case but it seems very easy to reproduce it in a
general way.
Thx again
Ed Merks wrote:
> Christian,
> There have certainly been a few bugs in the case of handling
> bidirectional references so that makes me wonder which version Mat is
> using. Definitely a test case is needed. We have quite a few tests in
> ChangeRecorderTest.java already, so I'm pretty sure this case should be
> working properly in EMF 2.3.
> Christian W. Damus wrote:
>> Hi, Mat,
>>
>> As far as I know, the ChangeRecorder is intended to handle mutation of a
>> bidrectional 1-to-many reference from either end. The only problems that I
>> have seen are in metamodels that have internal side-effects, such as MDT
>> UML2's superset-subset feature synchronization.
>>
>> In any case, you absolutely should not be required to make either end of
>> this reference derived. That wouldn't make sense.
>>
>> I suspect that something more is going on, here. Can you raise a bugzilla
>> with a reproducible test case attached? (preferably a JUnit test) Then I
>> can have a look to see where the problem lies.
>>
>> Thanks,
>>
>> Christian
>>
>>
>> Mat Lo wrote:
>>
>>
>>> Hi,
>>>
>>> My model looks like that : I have 2 classes that reference each other
>>> ("opposite" )with a 1-many relationship:
>>> A.myBList
>>> B.myA
>>>
>>> The problem is, when I do a a1.getmyBList().add(b1) and I undo this,
>>> everything is fine.
>>> But, when I do a b1.setmyA(b1) and I undo this, I get
>>> BasicEList$BasicIndexOutOfBoundsException (see stack at the end)
>>>
>>> The thing seems to be that, when recording changes, the Transaction is
>>> notified and record 2 changes (in both cases) and try then to undo 2
>>> sub-operations.
>>> In the first case, it seems to work by chance whereas in second case, the
>>> elements seems to be tried to be removed twice.
>>>
>>> The problem may not occur if one of the reference is derived (because
>>> BasicChangeRecorder.shouldRecord then returns false).
>>>
>>> Is it a bug or is it mandatory to have one end of a bidirectionnal
>>> relationship derived?
>>>
>>> Thx
>>>
>>
>> -----8<-----
>>
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:56:33 GMT 2024
Powered by FUDForum. Page generated in 0.03507 seconds |
] 
Search
Help
Register
Login
Home
