Home » Modeling » EMF » [CDO] Legacy mode : "Legacy object has been registered multiple times"
| [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629166] |
Mon, 27 September 2010 12:12  |
|
Hi everyone !
I'm currently using CDO with no Passive Update Mode, as my CDO Objects must be updated in an EMF Transaction (see my previous post http://www.eclipse.org/forums/index.php?t=msg&th=175538).
Following Eike Stepper's idea, I use an other Session, defined with the same connector, for getting all CDOSessionInvalidationEvent and refresh properly the changed elements.
This solution works perfectly in most cases, but some problems occured when trying to deal with Legacy Objects. I'm using CDO 3.0, and can't upgrade to CDO 4.0 ; so I've defined a fork of CDO 3.0 applying the patches corresponding to the bug 320837, 323308 and 318518.
Most of Legacy objects are correctly committed and refreshed, but I encountered an issue when trying to commit CDOLegacyWrappers related to some of my EObjects. The commit pass successfully, but when I open the resource containing the Wrapper with the CDOSession View or when trying to load this resource programmaticly, I get the following warning : "Legacy object has been registered multiple times:".
When I try to modify this Legacy Object, I raise the following exception :
java.lang.IllegalStateException: Duplicate ID: CDOLegacyWrapper[OID27, ***]
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. registerNew(CDOTransactionImpl.java:1428)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. registerDirty(CDOTransactionImpl.java:1416)
at org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition .execute(CDOStateMachine.java:806)
at org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition .execute(CDOStateMachine.java:1)
at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:162)
at org.eclipse.emf.internal.cdo.CDOStateMachine.writeWithoutVie wLock(CDOStateMachine.java:384)
at org.eclipse.emf.internal.cdo.CDOStateMachine.write(CDOStateM achine.java:369)
at org.eclipse.emf.internal.cdo.CDOStore.getRevisionForWriting( CDOStore.java:625)
at org.eclipse.emf.internal.cdo.CDOStore.remove(CDOStore.java:4 21)
at org.eclipse.emf.internal.cdo.CDOLegacyAdapter.notifyChanged( CDOLegacyAdapter.java:113)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:380)
at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(E coreEList.java:255)
at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove( NotifyingListImpl.java:719)
at org.eclipse.emf.common.util.AbstractEList.remove(AbstractELi st.java:466)
at org.eclipse.emf.ecore.util.EcoreUtil.remove(EcoreUtil.java:2 993)
After an investigation, it appears that
CDOTransactionImpl(CDOViewImpl).getObject(CDOID, boolean) line: 969 creates the InternalCDOObject twice (by calling createObject).
It's a bit fuzzy for me : does this mean that when I committed by Legacy object I did something wrong ? Or is it a problem that only concerns loading ?
Moreover, I don't get what this message means : how can I register multiple CDOLegacyWrappers with the same ID ?
I'm very aware that this problem is very specific, but if someone has the time to explain me what I do wrong it would be great !
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629262 is a reply to message #629166] |
Mon, 27 September 2010 15:41  |
|
This is a multi-part message in MIME format.
--------------050108020308050003050704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
You mention several areas (passive updates, legacy mode, multiple sessions, ...) so that I'm having problems to immediately see the reason for you issue. Is it possible that you:
1) try this with HEAD sources or a recent 4.0 build?
2) If the problem is the same in HEAD, try to write a test case that reproduces the issue? In our test plugins there a hundreds of example on how to write CDO tests. It's really easy.
If you ansered "yes" to question one, please write a bugzilla. Without a test case it's unlikely that we'll fix a problem soon.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
I'm speaking at Eclipse Summit Europe 2010 <http://www.eclipsesummit.org/>
Am 27.09.2010 14:12, schrieb alagarde:
> Hi everyone !
> I'm currently using CDO with no Passive Update Mode, as my CDO Objects must be updated in an EMF Transaction (see my previous post http://www.eclipse.org/forums/index.php?t=msg&th=175538).
> Following Eike Stepper's idea, I use an other Session, defined with the same connector, for getting all CDOSessionInvalidationEvent and refresh properly the changed elements.
> This solution works perfectly in most cases, but some problems occured when trying to deal with Legacy Objects. I'm using CDO 3.0, and can't upgrade to CDO 4.0 ; so I've defined a fork of CDO 3.0 applying the patches corresponding to the bug 320837, 323308 and 318518.
>
> Most of Legacy objects are correctly committed and refreshed, but I encountered an issue when trying to commit CDOLegacyWrappers related to some of my EObjects. The commit pass successfully, but when I open the resource containing the Wrapper with the CDOSession View or when trying to load this resource programmaticly, I get the following warning : "Legacy object has been registered multiple times:".
>
> When I try to modify this Legacy Object, I raise the following exception : java.lang.IllegalStateException: Duplicate ID: CDOLegacyWrapper[OID27, ***]
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. registerNew(CDOTransactionImpl.java:1428)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. registerDirty(CDOTransactionImpl.java:1416)
> at org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition .execute(CDOStateMachine.java:806)
> at org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition .execute(CDOStateMachine.java:1)
> at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:162)
> at org.eclipse.emf.internal.cdo.CDOStateMachine.writeWithoutVie wLock(CDOStateMachine.java:384)
> at org.eclipse.emf.internal.cdo.CDOStateMachine.write(CDOStateM achine.java:369)
> at org.eclipse.emf.internal.cdo.CDOStore.getRevisionForWriting( CDOStore.java:625)
> at org.eclipse.emf.internal.cdo.CDOStore.remove(CDOStore.java:4 21)
> at org.eclipse.emf.internal.cdo.CDOLegacyAdapter.notifyChanged( CDOLegacyAdapter.java:113)
> at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:380)
> at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(E coreEList.java:255)
> at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove( NotifyingListImpl.java:719)
> at org.eclipse.emf.common.util.AbstractEList.remove(AbstractELi st.java:466)
> at org.eclipse.emf.ecore.util.EcoreUtil.remove(EcoreUtil.java:2 993)
>
> After an investigation, it appears that CDOTransactionImpl(CDOViewImpl).getObject(CDOID, boolean) line: 969 creates the InternalCDOObject twice (by calling createObject).
>
> It's a bit fuzzy for me : does this mean that when I committed by Legacy object I did something wrong ? Or is it a problem that only concerns loading ?
>
> Moreover, I don't get what this message means : how can I register multiple CDOLegacyWrappers with the same ID ?
> I'm very aware that this problem is very specific, but if someone has the time to explain me what I do wrong it would be great !
>
>
>
--------------050108020308050003050704
Content-Type: multipart/related;
boundary="------------000705010103010801040304"
--------------000705010103010801040304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
You mention several areas (passive updates, legacy mode, multiple
sessions, ...) so that I'm having problems to immediately see the
reason for you issue. Is it possible that you:<br>
<br>
1) try this with HEAD sources or a recent 4.0 build?<br>
2) If the problem is the same in HEAD, try to write a test case that
reproduces the issue? In our
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
test plugins there a hundreds of example on how to write CDO tests.
It's really easy.<br>
<br>
If you ansered "yes" to question one, please write a bugzilla.
Without a test case it's unlikely that we'll fix a problem soon.<br>
<br>
<!--WISESTAMP_SIG_63187_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers<br>
/Eike<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.04030905.03050400@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.06050406.02050404@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.08010202.02040003@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.01070804.06000406@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
<div><br>
<a href="http://www.eclipsesummit.org/"><img
src="cid:part5.08040601.09030102@esc-net.de" alt="I'm
speaking at Eclipse Summit Europe 2010" border="0"
height="100" width="100"></a>
<br>
<br>
</div>
</div>
</span><!--WISESTAMP_SIG_63187_END--><br>
<br>
Am 27.09.2010 14:12, schrieb alagarde:
<blockquote cite="mid:i7q1hm$o6v$1@news.eclipse.org" type="cite">Hi
everyone ! <br>
I'm currently using CDO with no Passive Update Mode, as my CDO
Objects must be updated in an EMF Transaction (see my previous
post <a class="moz-txt-link-freetext" href="http://www.eclipse.org/forums/index.php?t=msg&th=175538">http://www.eclipse.org/forums/index.php?t=msg&th=175538</a>).
<br>
Following Eike Stepper's idea, I use an other Session, defined
with the same connector, for getting all
CDOSessionInvalidationEvent and refresh properly the changed
elements. <br>
This solution works perfectly in most cases, but some problems
occured when trying to deal with Legacy Objects. I'm using CDO
3.0, and can't upgrade to CDO 4.0 ; so I've defined a fork of CDO
3.0 applying the patches corresponding to the bug 320837, 323308
and 318518.
<br>
<br>
Most of Legacy objects are correctly committed and refreshed, but
I encountered an issue when trying to commit CDOLegacyWrappers
related to some of my EObjects. The commit pass successfully, but
when I open the resource containing the Wrapper with the
CDOSession View or when trying to load this resource
programmaticly, I get the following warning : "Legacy object has
been registered multiple times:".
<br>
<br>
When I try to modify this Legacy Object, I raise the following
exception : java.lang.IllegalStateException: Duplicate ID:
CDOLegacyWrapper[OID27, ***]
<br>
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.
registerNew(CDOTransactionImpl.java:1428)
<br>
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.
registerDirty(CDOTransactionImpl.java:1416)
<br>
at
org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition
.execute(CDOStateMachine.java:806)
<br>
at
org.eclipse.emf.internal.cdo.CDOStateMachine$WriteTransition
.execute(CDOStateMachine.java:1)
<br>
at
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite
StateMachine.java:162)
<br>
at
org.eclipse.emf.internal.cdo.CDOStateMachine.writeWithoutVie
wLock(CDOStateMachine.java:384)
<br>
at
org.eclipse.emf.internal.cdo.CDOStateMachine.write(CDOStateM
achine.java:369)
<br>
at
org.eclipse.emf.internal.cdo.CDOStore.getRevisionForWriting(
CDOStore.java:625)
<br>
at
org.eclipse.emf.internal.cdo.CDOStore.remove(CDOStore.java:4 21)
<br>
at
org.eclipse.emf.internal.cdo.CDOLegacyAdapter.notifyChanged(
CDOLegacyAdapter.java:113)
<br>
at
org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify
(BasicNotifierImpl.java:380)
<br>
at
org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(E
coreEList.java:255)
<br>
at
org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(
NotifyingListImpl.java:719)
<br>
at
org.eclipse.emf.common.util.AbstractEList.remove(AbstractELi
st.java:466)
<br>
at
org.eclipse.emf.ecore.util.EcoreUtil.remove(EcoreUtil.java:2 993)
<br>
<br>
After an investigation, it appears that
CDOTransactionImpl(CDOViewImpl).getObject(CDOID, boolean) line:
969 creates the InternalCDOObject twice (by calling createObject).
<br>
<br>
It's a bit fuzzy for me : does this mean that when I committed by
Legacy object I did something wrong ? Or is it a problem that only
concerns loading ?
<br>
<br>
Moreover, I don't get what this message means : how can I
register multiple CDOLegacyWrappers with the same ID ? <br>
I'm very aware that this problem is very specific, but if someone
has the time to explain me what I do wrong it would be great ! <br>
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------000705010103010801040304
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.04030905.03050400@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------000705010103010801040304
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.06050406.02050404@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------000705010103010801040304
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.08010202.02040003@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------000705010103010801040304
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.01070804.06000406@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------000705010103010801040304
Content-Type: image/gif;
name="100x100_speaking.gif"
Content-Transfer-Encoding: base64
Content-ID: <part5.08040601.09030102@esc-net.de>
Content-Disposition: inline;
filename="100x100_speaking.gif"
R0lGODlhZABkAOZ/APb3+VNYfigtUDRDchhWpwM6mkRXjThrsCdirVJ7u0p2 uExflWyGrQU0
asnX6aq31ImZUxRFoaOqOWaIwgRGlubr87bG4C44YMHDzmeGZYqMrtLRFuHi 5zpalGxskRZD
lVt/vdHZ6TRlqzlTiJiy1Wd7qExtrB00XDtfnH2SvyFeq0ZttQlTo9vi7lNt qTRfryVJlkVr
rXmEkYebxLKzvPDqAi9ZrANMniZGgTpMfh4dNSpWk4OjywI6flx0qIV2rDxk pD5psQNBiyw8
jjpksJSkx4OImhtFi2CEv0NjornAMCBRoYqq0uvw9zNor4SBRj5xtcbGHr65 HDRhoxVPoyRR
pypWqg0/nB5aqSE+bUU/kCpQh1NRKildo05ppUBnqh1LpJOt0ZecsaCJwkRH aU5yozRMmGpY
nz5sgk9knmyPw6alwDk+YNPT3uLdCkVop2BggnaOvC1lrre5TBc7fVB7fRFP lRtakkNfmnyc
yypVnyxdrcTQ5O/v8v///////yH5BAEAAH8ALAAAAABkAGQAAAf/gH+Cg4SF hoeIiYqLjI2O
j5CRkpOUlYp+mE2amhUOm5uYfpajpIiZfHl5SKsgra4gCbEJamopFU2YpbqT fk0OeRPBq6yv
ssYJCskKSGoVubvQpn6/wcLErsexysor3d1BzaLR471M1dZI2LLb297u30Hx CRbi46Tl5xPX
6+3v7vEAARIZSOQFPXuVevHIl66VtmTvAhKcSHHii4sXbRxECMkPn3P7IHqL RxGjyZMoTdpY
ScQZR0bTQDZ8CG8gxpU4rejcydMKzp9AdyYA8DKRx2rEtI20+WLlzipQo0qd GrWnVagvKhQ1
5EcNUofIvjG1oVMqmLNo06pNS7Ut1I1F/2Nac6hAbMayVdJG2Mu3r9++a8FQ TauA6Eu5+ujW
DWKTLFS9fq9Inkz5yt+9gTNbMWxPbtK6Kxg3tfL4bN/KqFNTvpwZzN4qnKHF HAYrrOgXZdHy
TV2gt+/fv1VfHg472uyZoEU7zut6L2rg0KP7Tj38NJjYozzTtevYtPPn0sNH Fx558nVdDoal
C7ui4B7SzHerliy+fvD5lQuAqVcJAG1YixXk2BLNRYDaBwgmSJ99DOK3YAFh ZKfGZ918UcaA
BRooWYIfwGDGhzDA8MEVDJZYAG/APZCQBRSuUIYESqDBXHOoDeFhB0nkiIIe H2qhxQAXBHlB
FnSYCB1l0mH3SP96DTEgAQRlBPGFEkpMAcYSGUCwQ2oe4uGFDyWAUMIPP5wR ABlksCGkAAKc
UKSRJUagJEy0JcCAG1GUcREKU+hxpQRujHAgDHqkUUIKRayxhgYewHFmmkJe wGabcJYYYUcs
zpSADDIISJppaKABw6Ao+JDCAyG0QQOjjqKp5pqTClApg3Mm0gQxDAT4wnvx yQcDDpN1mIQP
M7RRQQir/tBqmmoKICmbOlA6q3h6POKHKiAwMIcSMoTmXhUEZnjFDk9u8YGN ZqDgQhEYtIHB
oo0+yoYAHtAwKRlGSPrmtNK14MitDSmxQQmi8UrgX0tEsYGB537owhiKiqHB Dx48mqb/ADJU
MGkAbbARLb/SXQEEf6Zg2woDJURJxHtWhHvZDjtoeAUMaZA5McUVe+ABGRfM KwMH0U6qw9BZ
9HbFEiQGRyB0FCyBdGr+LtKEOgGKsCt84YJBxdZUnJZEqhW00WijcGBQAQcV GMHmz0FzfEG0
bFiQAh99tNBB0kCEoDcfo/a2BB98hGDBqJWNfEke2ICQHGMFpXTSG3uYUEEa A+QQwho5wLFA
G23w7IEMPRvBgbNseAAAGQKwQQYADxiQwxoV4HAEDE2UkEUOJRhwRIchlIAD DuzuTpkQHFwy
gUPaQqAA4xjt4fzz0E9RhwRoFGHBCDq3ewEZpgegw7NBiu7s/wVw9DGvAGT0 sUAWOIwAwAJ0
wOBHCjngQIfsV7zBwQJpdOADACMQ3hWEIIQiGMUC2GBADeawggMQwWrQi2DL QvSEGsDhARzA
AB84JwZnlaAPkmKDCNUkPmeV71npSwMOEFQBH6zQCxXoAwcYILwSAAADGHiA DgOIIAIKoQd9
MMXxamMngjHGalZ7gQiWSJAk2qAMJRgBCWhwghwEIAfOGoDpUEeGHFRuAOIL UvnmtT31rVAP
75PdEXCwAA34oQS78wEHBvC7Ou7uAwTsQQ/4gAgAEDEZUIiHEy4SwUJCzwoR cIEfFqCFM1Cs
Z2SowBqixT01/WxSJ4RbH3xAhw+koP8FslvCFD5AhyNUQAOdRKMGZAeDJIho RHnsAQoO4ZHa
cCMIBxCBHAxpyClYKUQa6EMIWgCANaSOfBzgQBv60EEBlFAA5ROAJpXJgRYs gJUtCMED3FU/
EcGQDw8Ap4gG+EM9HiGIhfDDBPgBhRhk6Q0qwAIB5jlPp3Fta3rIQAYIdC4D lIBR58PkzoaW
OjIQFH1Di1YLSsDQEciOAhSAgQ8Y4ILfwWBrYBhBCShavyOQU496bANX1qkN KEChDFFwQx3i
KU96zvOeVEDBBtywAzDAYAhDuEAjzxBQaSZUaEHzKdEmV8ojHAGiEP2AUUN0 T5vaEY+x1KMB
C9EEdkLhAPr/BAJLXcrVeWIhA3VYwk1xOgQtkAkOz4qVWmOVUB184AELOCpS KXADukYAplQg
wD0RRIGompM/HmHnAZwgBwTsQQVdwEJLu9oFeoo1RCHKQSPH8APUrfWybaUD BT7wULre4LOg
helLuRYBiPq1B+ckhB+Q8BCTDnaXKkDDk6bgVXp2AQLUsykMwjUCCUghCnA4 A2Ute1mgDu0E
c6UABOoAWtCygGsuvadpT7tH1aqhtVclLAJUAIQNRKGxXahDBsALKAM4jQBY cBoEpGAGOMDB
rMNV6/k81tYLfGCzdb1BBtCgXwncgQXPzStXuWaH6ZYTpD0Q6SDUid3Xbje8 dZAn/woUhgbF
hiqxik3vEiCwgRGUVQtSgMAP5iABATwhClLYgG/d8IShSeG3T9qAEuxwAwnU 4Q4z9e/WuqrX
rdW1r6dtgBgIUQFjKMC12lUBSzOcJQxn+MnpJVcNnuCjDVBZCXM4AwRqwIUK djkKOmBDDTKw
hTHfoQb83UAGbgABJdxhxzzm2o99iOAGNIAO9aiqYJO8ZCj7GcpVgEEGpmyG KFBZAhLQAgSi
MIQnSMHEUhjCFtxwBDu4ga5ovkEU1tzm59Izw/T08Zz9auct5JkfR3bwdv+s 2Hj2maV6gAEY
1msGK2shCok+sRYc3WgpfGDSlXbDHSzN302zWQks+DSoX//Kgh8D+cA9sDMO Tv2QVKu6z09W
srZdrVgIQCADbsgADCSg4hpAoNGMPvEH1F3mSqP5Dm5IcwZYAG4INBbKof4s UukMUmlTGxlH
vuq1sY2FbRscC3pAw7fRoIcqjCADjgoADAwg8REE4Ncj+IAd+HuDOtiBBR7v +H/pnQF54rvH
oDVwv/09iCI3+LWF3a6Ss61tBNgcsXqwwratEOvdPhayr9zLxwHcXOcCONle LfhW9dpsfQO5
ztLmDB8ADkiBEzbmMjd4zW3eBT104eba7jrP9aAHp5n9nkc/etHTnnRtK3ae RHc2qe1MB3T+
oQnsMGl2tWvzrGu973rYQ98H34X/Lmz7yVxNu9o/y3b0Kn3mLY37vqFt5wZs gRB434beB3v1
wWtdBX3vguDlQHrSc33wfl86PRXPeq9qPfJNH/XKWS6IzFcdyYRVAAkUgPqt I0D0pQ8+1lEP
dpaCgAmrlwMTENB69L5enpKf7uwbMO1B2D7gSPYDCSagTuITHgHCl4MTrl56 8BNf20zwg0sT
4AcFKL7tSs469GMvfT1Wnvr1qIAy9C7wA2hfDn5get7Xd8I3fgY4fuE3fCoQ Bn7wdnDXfI9X
fPMHWnyQAlF1f9VXe9i3eQfgfyQgBx/oAA5ADxaQB37QAgdgc6THBADgBxXg BCTgBzzgggng
BDzgDBZA/3oOgAl8cAAMqAJ50AIIwH4JwALat4NqgAVysIMOAABhIHNYQAIt GAIHMIMeUU73
1wAjUA+rxX+uNVj/p4MAkAd8oH0xOAHgR3p+kIMKAIPaZ4IWAAUAwARQ0BVy AAJyoAarxYAJ
UAFQgAVEaIT+0QlYwIKxoH03hwUKQAAqIIM3IIOxlIUYUAhI4IUdCIYfqIMO AIIByH0TEHx5
UAEtkAdu2IEiqIehQAJQQA+YMAExCAB8EE8g4AdF6AdMwAIiiAUiCHqIKHMs iAk88Ig8cGCS
WAhqwH+XiIlXJ4KcKAeeGH4xCAIxeFUVYAHsxwQGmH4g4IkxaII8oAKzmAAE YP+LuOgAWGAB
AOAESNCLQyiD4xiMkDh9DTCJRIaMl+gE2reMmxiDzqhOwdcJoggFMcgHFQAA CXAAMSiC23eC
ZWgB/EgPq+AHIDCOyCeCBLCOa8iOTgAA1ciRFBACTfAA9nd/WYAdTdB/9+gE aqAApdcKcqAA
nwgFE3AAwQeTEzB+07iSlzgLajB+CYAE6ogEMEl666SOcgCITkAAULCIcgAF lXgtAugEE+kE
ClBgZbADI1l5OYAdtJiMHXiATrBES5SAwrdEOOkHXpmMB8h5CBh8q9ZVhdGE KCiAhpdedlBg
kXh/NHAIapCSYKlLYikHupSAYikCPtmXHRgPXjl+ann/gOW3ZJ8mB6ylgnRp l3iZlZVHj4XQ
AgdomGEZloUZmtsnAqNZmAZ4iQGhmGn5lZ85mDFHcPGXhoW1B12ABGGwBHZw BFh4fycwJ34A
BaG5RKGgfcFJnMRpmk5wALiknKnplTfoB/5hgGNZfnWZYTUXfLTJgDsAA0ZF B9F2f0ZAMoMw
AcEpAsdZnucZnInJnKmZmrAYBKx1iUs0eqRHm68Wm4I5BYWnBztQBnxQBnSQ hfOYCBWAniRQ
mEzgDAVqnAeqN/QQAvHAihYQBBPQAn4QAiAQEKKoBvGgh2pABNq3ByJIgibY ApIpgwDgHxaa
B1OgnWXoBzMQoFpZK4IQA77k/0vCGQoioIdMIAIJYJ4HSpwhAAA8EIM8oIc8 EAQZGgJ8EAMt
8AABgQQ4qAAeGgTaNwVNSIbax4ARaQF62ALN4ABdoJ0l4Ac+kAVZcAKVt5eK 8AA3eqPaBwRy
GoNyCgRACqR5EwJf8AXa9wUPAItqEAPDGQIxUKjxEAMM6KVdYaUHKoJdEIMi wH0RiQRd4Adh
0AWOyoBbUKZnmqYnoKbFcwlv6ktxKqcz0BV1Gqd9OkxfwH488AUxoAB8AAAx UAFNWqi4GquF
2gJ8oId5MIMkQASZ6gc7qk6SWqmXKoI7oKk+YKZo+qknIAON4KYowCco4IIO oE15c6EVMDIk
4K1fEP8CxwIALfAFapBNAGABMZAH5MqkuXqhxHQ8LUgPJBCuIdCindgVekip lqoHyloEfrAF
C9AHp+SpJxCqiwAA1bqwDNCwDAACcgoCauADQHBd5poA9poAcbCnXzABcTAB uJoAKRAHCWAC
uKoAcRAHuLqNMWCxqwAECTABUwAO3RCoU4AEMaAHZVAGW4AHLoQDOeABAwCt 0uoID7CwSIu0
dVqnXwAEe6o3X/AGUvsGuGoCVnu1WFu1MWC1ucqxXgsEUyACRMCxvsSfO7AF W1BHaGqwB/sI
AFAGHZC0Sbu0dZoEb7AKU0u1hYq1fHu1e8u3uOq1HGunTrunQIACHXC2afv/ O2sLrSegAZHA
AR0wuZQbt3Mrp0kABHabt1O7tX3bt54LujEgtYLbtEubBIjbAWjLuM8KrasT CX4At5U7uXKr
uTmyuVIbB8OZAnzrAibgu58LunkruJmLuXjQASMwAmnbuI7LppEAAF4wu5Qr t7eLu7obB17g
BVfrAtzbvcAbvFg7tcSbI3hQrcc7AjngRa0LrUZAo4sgudI7vQtbvVN7vdpr Ag/gBy6QAvOj
SAT5ABMQAtD5APjrBwBbASDgBRV6oRRru0lwvJObvF40AFlwAY7LBu7LCA+Q vByMvJWLAuWL
B7f7Bl6gu5gQAi6Qv/vbvyc4AyUwTD4AsKfiBw9w/6oW4AVMmgRPergLS7kS PMFBAq1soGAJ
4QUcfMSziwdKfLsl7AfY6wUprL/8mwKK9ADcS8NWS8Mq7AJ64wWD2sMRLMED MMZCAq3Oawl9
YABHjMSUq8QinARpYL9QnL8+QA9UTMPca6tewAAGTMcuUI3f9MDV6sM/PMZA EsSf2r66kMZr
zMYd4MZ4EMcnqDdFcKoZeccPkL0zQK4AEAJekL8ECQAl4AUp0K58EMboO8Fk XMbOJJ5o7Drp
mwONbAAG8MhKXMIpGwejjDKm4gP7O8rZ6wNxwADZS8cp4ANekAaR3LB4wMHp a8iHDCvhOQ5p
HMuxvMa0bAB4sADczD9p8P/NaZC94gzO5PzN+UvOC4AHtOzMz0zBFYzIbDLN 9lDN1py+R5zN
BtDN3FzO/MzPwvzN3bzOsQzN7wytkyLPCNEHqVzP9py8+KzPEK3PkBzRAa3G 7bzKFvypsYLQ
HNEHmGPIDC3LI4DP+azPJH3SKA3LqvzOGR0rF0ADrowQawDNYxzSI53SJM3B Of3DqhwpGh0r
ZEDEW9FyqgzNIW3NC33UR23IZfzTG53BHFEBYkDTVK3UVn3RhvwqaSVfMD3U isABcEDVYj3W
ZJ3VIgQra6XIXp2wGBAAZf3WY/wqWh0pWx0rMiDUa83WATBCdN3Xfv3XQVJc d53XknBDYgDY
iE1P18XFJmRAA3hN2JHb1okd2IstXzJAA1AN2Y0AABmkATyD1pU9KapDA5it 2fbA2ThkBGiy
2vMyQiLU2KSdoqbt1Sla25xt2y0427q924UQCAA7
--------------000705010103010801040304--
--------------050108020308050003050704--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629277 is a reply to message #629166] |
Mon, 27 September 2010 16:19 |
 Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi,
comments inline.
>
> After an investigation, it appears that
> CDOTransactionImpl(CDOViewImpl).getObject(CDOID, boolean) line: 969
> creates the InternalCDOObject twice (by calling createObject).
>
> It's a bit fuzzy for me : does this mean that when I committed by Legacy
> object I did something wrong ? Or is it a problem that only concerns
> loading ?
>
I guess that this is somehow related to your setup, although I have no
real idea yet. You could try to convert your model to CDO native (if
possible) for testing reasons and then load your model again. If I am
right then you should not experience any trouble. So this would mean
that the problem starts when the legacy objects are loaded.
> Moreover, I don't get what this message means : how can I register
> multiple CDOLegacyWrappers with the same ID ?
Legacy objects are normal EMF objects (should I say "Plain Old EMF
Objects"? ;)) which do not know anything about CDO.
The CDOLegacyWrapper cares for the synchroisation between the repository
and the EObject. When an object is loaded from the repository the
wrapper loads the object and all it's containments, container, opposites
etc. While this is done it could happenthat an object is registered
twice (due to a cyclic relationship). Under normal circumstances this is
no problem for CDO. But in your scenario it seems to lead to the trouble.
> I'm very aware that this problem is very specific, but if someone has
> the time to explain me what I do wrong it would be great !
>
I don't think that you did something wrong.
As Eike suggested the best would be to write a test case and check if
the problem occurs on CDO 4.0, too. With this test case we could better
investigate this problem.
Cheers,
Martin
>
>
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629394 is a reply to message #629277] |
Tue, 28 September 2010 06:56 |
|
Thanks a lot for your fast replies !
Now I understand a bit better what is happening. As Martin suggested, I'm currently converting my models in CDONative, but this operation is no trivial at all as the feature delegation in cdo causes a lot of modifications in the existing code.
I let you know if the native models cause any issue. If not, as soon as I have time I will write a testCase in CDO 4.0.
Thanks again !
Alex
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629693 is a reply to message #629394] |
Wed, 29 September 2010 09:47 |
|
After investigations, I identified more precisely the causes of the "Duplicate ID" error.
This occured when CDO loads the following Legacy Object :
I've got an EObject A from a MetaModel M1, containing, at several level of containment, an EObject B from a MetaModel M2. B references A (it's the case of cyclic relationship described my Martin Fluegge in his last post).
When the EObject A is commited (using Legacy Mode), everything goes well. However, when the resource containing A is loaded (for example when calling getContents() ), a problem occurs :
- in a first call to "getObject(OID-A, true)" in CDOView, an instanceof A is created (as localLookupObject is equal to null).
- as A is not CDONative, a CDOLegacyWrapper is created and registered (CDOLegacyWrapper.cdoInternalPostLoad() -> call to registerWrapper()).
- Later, when creating B, the B associated Legacy Adapter tries to get the referenced element A using its OID (CDOViewImpl.convertIDToObject(OID-A).
- This calls the getObject(OID-A,true) method in CDOView. Clearly, as the LegacyWrapper associated to A has been created and registered, the localLookupObject should be the LegacyWrapper associated to A, but is null.
- As the localLookupObject is null, A is instanciated twice, and a new Wrapper is created for A, with the same ID.
Hence the "Duplicate ID" error, as the OID-A is associated to two differents wrappers.
I think the problem is that when the first LegacyWrapper created for A is registered, this wrapper should have been also registered in the objects map of the view, and not only in the wrapperRegistry of CDOLegacyWrapper.
Another solution could be to use the CDOLegacyWrapper.getRegisteredWrapper(CDOID) method in the CDOView if the objects.get(id) returns null.
What do you think about this ? Is this a regular behavior and am I missing something ?
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629962 is a reply to message #629693] |
Thu, 30 September 2010 06:35 |
Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Am 29.09.2010 11:47, schrieb alagarde:
> After investigations, I identified more precisely the causes of the
> "Duplicate ID" error.
>
> This occured when CDO loads the following Legacy Object :
> I've got an EObject A from a MetaModel M1, containing, at several level
> of containment, an EObject B from a MetaModel M2. B references A (it's
> the case of cyclic relationship described my Martin Fluegge in his last
> post).
> When the EObject A is commited (using Legacy Mode), everything goes
> well. However, when the resource containing A is loaded (for example
> when calling getContents() ), a problem occurs :
> - in a first call to "getObject(OID-A, true)" in CDOView, an instanceof
> A is created (as localLookupObject is equal to null).
> - as A is not CDONative, a CDOLegacyWrapper is created and registered
> (CDOLegacyWrapper.cdoInternalPostLoad() -> call to registerWrapper()).
> - Later, when creating B, the B associated Legacy Adapter tries to get
> the referenced element A using its OID
> (CDOViewImpl.convertIDToObject(OID-A).
> - This calls the getObject(OID-A,true) method in CDOView. Clearly, as
> the LegacyWrapper associated to A has been created and registered, the
> localLookupObject should be the LegacyWrapper associated to A, but is
> null. - As the localLookupObject is null, A is instanciated twice, and a
> new Wrapper is created for A, with the same ID.
Yes, that's the nature of legacy. A legacy object is registered *after*
is is created. The problem is, that while it is created it creates all
it's references. In case of contaiments this obviously leads to trouble.
We have a mechanism to prevent the double registration but it seems that
it fails in your your case.
> Hence the "Duplicate ID" error, as the OID-A is associated to two
> differents wrappers.
>
> I think the problem is that when the first LegacyWrapper created for A
> is registered, this wrapper should have been also registered in the
> objects map of the view, and not only in the wrapperRegistry of
> CDOLegacyWrapper.
Hmmm, sounds good. Actually I thought there was a reason why we did not
do that. But I cannot remember which it was... ;(
> Another solution could be to use the
> CDOLegacyWrapper.getRegisteredWrapper(CDOID) method in the CDOView if
> the objects.get(id) returns null.
Legacy is just an add-on to the CDO core. Dependencies from the Core to
legacy should in general be avoided - or at least kept to a minimum.
> What do you think about this ?
I think you should file a bugzilla for this ;) There we could clarify
what's different in your scenario compared to our tests and then fix it :)
Cheers,
Martin
Is this a regular behavior and am I
> missing something ?
|
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #629963 is a reply to message #629693] |
Thu, 30 September 2010 06:58 |
|
Just for the record, I tried to modify CDOViewImpl :
As I suggested, a solution can be to check, if the objects map doesn't contain any object associated to the searched CDOID, if a LegacyWrapper has been created but not properly registered in the objects map (as its creation is not complete) :
InternalCDOObject localLookupObject = objects.get(id);
if (localLookupObject == null)
{
+ localLookupObject = CDOLegacyWrapper.getRegisteredWrapper(id);
+ }
+ if (localLookupObject == null)
+ {
if (id.isMeta())
This solution seems to work perfectly, but I have no time for writing a test Case and test the non-regression right now.
BTW : as the my metamodels associated to my legacy objects are pretty complicated (contain a lot of user code, use a complete genModel...), I noticed one or two things that caused problems (most are ClastCast Exceptions).
For instance, in CDOLegacyWrapper :
- InternalEObject obj = (InternalEObject)list.get(i);
+ Object obj = list.get(i);
// TODO Clarify obj.getClass()/baseclass
((InternalEList<?>)list).basicRemove(obj, null);
Why should list.get(i) be casted in InternalEObject ? It causes problems when enumerations implements Enumerator.
Again, no time for testCases right now...
Thansk again for all your help !
Alex
EDIT : just saw your answer. Obviously this solution is a hack, and should be rewrote 
[Updated on: Thu, 30 September 2010 07:01] Report message to a moderator |
|
|
| Re: [CDO] Legacy mode : "Legacy object has been registered multiple times" [message #630063 is a reply to message #629963] |
Thu, 30 September 2010 14:30 |
Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
comments below...
Am 30.09.2010 08:58, schrieb alagarde:
> Just for the record, I tried to modify CDOViewImpl :
> As I suggested, a solution can be to check, if the objects map doesn't
> contain any object associated to the searched CDOID, if a LegacyWrapper
> has been created but not properly registered in the objects map (as its
> creation is not complete) :
>
> InternalCDOObject localLookupObject = objects.get(id);
> if (localLookupObject == null)
> {
> + localLookupObject = CDOLegacyWrapper.getRegisteredWrapper(id);
> + }
> + if (localLookupObject == null)
> + {
> if (id.isMeta())
>
>
> This solution seems to work perfectly, but I have no time for writing a
> test Case and test the non-regression right now.
As stated in my previous post it is not a good idea to put too much
legacy dependencies into the CDO core. To register the wrapper to the
view looks quite more promising. ;)
>
> BTW : as the my metamodels associated to my legacy objects are pretty
> complicated (contain a lot of user code, use a complete genModel...), I
> noticed one or two things that caused problems (most are ClastCast
> Exceptions).
> For instance, in CDOLegacyWrapper :
> - InternalEObject obj = (InternalEObject)list.get(i);
>
> + Object obj = list.get(i);
> // TODO Clarify obj.getClass()/baseclass
> ((InternalEList<?>)list).basicRemove(obj, null);
>
> Why should list.get(i) be casted in InternalEObject ? It causes problems
> when enumerations implements Enumerator.
>
Seems to be a relict from an older iteration. Could you also file a bug
for your ClassCastException? Then I'll fix this asap.
> Again, no time for testCases right now...
>
Hmm, I wonder that you have time to dig through the internals of legacy
but not for writing a small test case ;)
Cheers,
Martin
> Thansk again for all your help ! Alex
>
>
>
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 09:00:54 GMT 2024
Powered by FUDForum. Page generated in 0.04558 seconds |
] 
Search
Help
Register
Login
Home
