Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 336382 - [Legacy] ObjectNotFoundException in LegacyMode
Summary: [Legacy] ObjectNotFoundException in LegacyMode
Status: NEW
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.legacy (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Christian Damus CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
: 338506 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-04 13:17 EST by Stefan Winkler CLA
Modified: 2020-12-11 10:47 EST (History)
2 users (show)

See Also:


Attachments
testcase (2.92 KB, patch)
2011-02-04 13:20 EST, Stefan Winkler CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Winkler CLA 2011-02-04 13:17:42 EST
I'll attach the TestCase to reproduce the problem.
For me, the TestCase fails at least with H2 DBStore in Branching mode.
Comment 1 Stefan Winkler CLA 2011-02-04 13:20:43 EST
Created attachment 188345 [details]
testcase

Testcase which leads to 


org.eclipse.emf.cdo.util.ObjectNotFoundException: Object OID2 not found in branch 2 at *
    at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:752)
    at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:668)
    at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:992)
    at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1)
    at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.getEObjectFromPotentialID(CDOLegacyWrapper.java:706)
    at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstanceResource(CDOLegacyWrapper.java:446)
    at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.revisionToInstance(CDOLegacyWrapper.java:405)
    at org.eclipse.emf.internal.cdo.object.CDOLegacyWrapper.cdoInternalPostLoad(CDOLegacyWrapper.java:281)
    at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.applyChangeSetData(CDOTransactionImpl.java:499)
    at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.merge(CDOTransactionImpl.java:466)
    at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.merge(CDOTransactionImpl.java:404)
    at org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_336382_Test.testPromoteToBranch(Bugzilla_3xxxxx_Test.java:54)
Comment 2 Stefan Winkler CLA 2011-03-01 09:46:09 EST
*** Bug 338506 has been marked as a duplicate of this bug. ***
Comment 3 Eike Stepper CLA 2011-03-08 00:51:39 EST
Disabling Bugzilla_336382_Test for now...
Comment 4 Eike Stepper CLA 2011-03-08 00:52:14 EST
Committed revision 7423:
- trunk/plugins/org.eclipse.emf.cdo.tests
Comment 5 Martin Fluegge CLA 2011-03-08 01:38:01 EST
After the EclipseCon I'll have a closer look at this one ;)
Comment 6 Vincent HEMERY CLA 2012-05-16 08:36:05 EDT
I think I have encountered this bug or a very similar one in a different context (using the CDO framework with H2, while developping an other application).

As I work in a different context and with not up to date sources, I can not guarantee you this will work, but I think I have found how to fix it :

At
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/internal/cdo/object/CDOLegacyWrapper.java#n555
I've changed the if condition after the comment "If you have a containment reference but the container is not set ..." :

Instead of 
if (object != instance.eContainer())
I think 
if  (object != instance.eContainer() && !object.equals(instance.eGet(feature)))
should work.

The reason is that sometimes, the framework just re-set the same value (don't know why exactly, maybe there should be a check for this at a higher level). When doing so, the "eInverseAdd" method does not work as expected, but removes the already set value.


Hope this will help.
Comment 7 Eike Stepper CLA 2012-06-05 07:28:27 EDT
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems.

Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Comment 8 Eike Stepper CLA 2012-08-14 22:54:58 EDT
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 9 Eike Stepper CLA 2013-06-03 05:54:08 EDT
Hi Christian, I assign this legacy mode zilla to you, just in case you're ineterested. Don't feel obliged ;-)
Comment 10 Eike Stepper CLA 2013-06-29 12:16:03 EDT
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.
Comment 11 Eike Stepper CLA 2015-07-14 02:17:41 EDT
Moving all open bugzillas to 4.5.
Comment 12 Eike Stepper CLA 2016-07-31 01:00:35 EDT
Moving all unaddressed bugzillas to 4.6.
Comment 13 Eike Stepper CLA 2017-12-28 01:20:23 EST
Moving all open bugs to 4.7
Comment 14 Eike Stepper CLA 2019-11-08 02:10:54 EST
Moving all unresolved issues to version 4.8-
Comment 15 Eike Stepper CLA 2019-12-13 12:46:02 EST
Moving all unresolved issues to version 4.9
Comment 16 Eike Stepper CLA 2020-12-11 10:47:48 EST
Moving to 4.13.