Community
Participate
Working Groups
When removing an EClass from an EPackage the exception below is thrown. Seems that there is something wrong in retrieving the correct list. java.lang.ClassCastException: org.eclipse.emf.internal.cdo.CDOLegacyAdapter at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.getList(BaseCDORevision.java:583) at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.getList(BaseCDORevision.java:577) at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.size(BaseCDORevision.java:437) at org.eclipse.emf.internal.cdo.CDOLegacyWrapper.cdoInternalPostDetach(CDOLegacyWrapper.java:201) at org.eclipse.emf.internal.cdo.CDOStateMachine.detach(CDOStateMachine.java:280) at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.detached(CDOResourceImpl.java:1172) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eBasicSetContainer(BasicEObjectImpl.java:1334) at org.eclipse.emf.ecore.impl.EClassImpl.eInverseRemove(EClassImpl.java:1412) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1447) at org.eclipse.emf.ecore.util.EcoreEList.inverseRemove(EcoreEList.java:318) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:716) at org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_XXX_Test.testMoveEcoreElement(Bugzilla_XXX_Test.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at org.eclipse.net4j.util.tests.AbstractOMTest.runBare(AbstractOMTest.java:150) at org.eclipse.emf.cdo.tests.config.impl.ConfigTest.runBare(ConfigTest.java:465) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at org.eclipse.net4j.util.tests.AbstractOMTest.run(AbstractOMTest.java:196) at junit.framework.TestSuite.runTest(TestSuite.java:232) at org.eclipse.emf.cdo.tests.config.impl.ConfigTestSuite$TestWrapper.runTest(ConfigTestSuite.java:126) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Created attachment 185874 [details] Test v1 This test makes the problem reproducible.
Created attachment 185879 [details] Test v2 Updated test case.
Created attachment 185881 [details] Patch v1 It turned out the CDOClassInfoImpl return a wrong featureID. Since all non persistent features are mapped to index 0 in the revisions values list it happened that the 'containingClass' feature (which is not persistent and has the featureId 17) was mapped to index 0 because the idMapping mapped from 17 to 0. This in return overwrote the value in the revisions value list at position 0 (which was the eAnnotions list) with the containingClass, when store.set() was called. For this reason a ClassCastExption occured when the revisoin tried to get the size of the eAnnotaions list, because the value was wrongly overwritten with the LegacyWrapper the mapped to the containingClass. I attached a patch that fixed the problem for legacy by not aligning none-persistent opposite features while an object is detached. But it might be that the root of the problem is in the CDO Core itself, to be exact in the id mapping of CDOClassInfoImpl. Eike, please let us discuss this.
Created attachment 185925 [details] Combined patch v1 I added skipUnlessConfig(LEGACY) to the test. I removed the line with the warning from the test.
Fix is good, but more places may be missing this fix...
> Fix is good, but more places may be missing this fix... o.k. I'll commit the patch to fix the issue and then I'll care for the other places. I suggest to keep track of the other changes on this bugzilla since the changes are somehow related.
Combined patch v1 committed to HEAD.
> I suggest to keep track of the other changes on this bugzilla since the changes > are somehow related. +1
Created attachment 185929 [details] Patch v2 I took care for the other calls of store.set() and optimized the CDOLegacyWrapper a bit. Happy new year ;)
Patch v2 is v2 of what? How does it relate to the previous non-obsolete patch? Where are the tests?
>Patch v2 is v2 of what? How does it relate to the previous non-obsolete patch? Patch v2 is an enhancement of the changes in the CDOLegacyWrapper provided in 'Combined patch v1' which was an enchancement of patch v1. Since 'Combined patch v1' had been already committed to Head and 'Patch v2' does not contain test (it is not combined), I called it just 'Patch v2'. So 'Patch v2' patched the committed state which was provided by 'Combined Patch v2'. >Where are the tests? Most parts of the patch are a cleanup of the legacy wrapper. So I tested agains all legacy tests.
If there were just a single patch active there would be no confusion but youforgot to obsolete my patch. Still "Patch v2" is not a good name as it suggests that it *replaces* "Patch v1"
Created attachment 185934 [details] Patch vA - code improvements >If there were just a single patch active there would be no confusion but youforgot to obsolete my patch. Guilty. I already fixed it. ;) >Still "Patch v2" is not a good name as it suggests that it replaces "Patch v1" Agreed. But neither would had been something like 'Combined Patch v2' since the patch was not combining anything - a vicious circle. Anyway, since the CDOLegacyWrapper has been moved to another package I have to apply an updated patch. To avoid any further confusion I named it 'Patch vA - code improvements'. Hope this makes the separation clear ;)
Created attachment 185936 [details] Patch A v2 - ready to be committed
(In reply to comment #13) > To avoid any further confusion I named it 'Patch vA - code improvements'. Hope > this makes the separation clear ;) No, Patch A v1 would have :P
Patch vA committed to HEAD ;)
Available in R20110608-1407
