Community
Participate
Working Groups
To test this remove skipConfig(LEGACY); from FeatureMapTest.doSetUp() org.eclipse.emf.cdo.tests.config.impl.ConfigTestException: Error in FeatureMapTest.testFeatureMaps [Combined, MEM, JVM, Legacy] at org.eclipse.emf.cdo.tests.config.impl.ConfigTest.runBare(ConfigTest.java:474) 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) Caused by: java.lang.ClassCastException: org.eclipse.emf.cdo.internal.common.revision.CDOFeatureMapEntryImpl at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$27.convertToEMF(CDOTypeImpl.java:647) at org.eclipse.emf.internal.cdo.CDOLegacyWrapper.getValueFromRevision(CDOLegacyWrapper.java:673) at org.eclipse.emf.internal.cdo.CDOLegacyWrapper.revisionToInstanceFeature(CDOLegacyWrapper.java:514) at org.eclipse.emf.internal.cdo.CDOLegacyWrapper.revisionToInstance(CDOLegacyWrapper.java:437) at org.eclipse.emf.internal.cdo.CDOLegacyWrapper.cdoInternalPostLoad(CDOLegacyWrapper.java:311) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.cleanObject(AbstractCDOView.java:883) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:834) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:701) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1002) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.convertIDToObject(AbstractCDOView.java:1027) at org.eclipse.emf.internal.cdo.CDOStore.convertIDToObject(CDOStore.java:596) at org.eclipse.emf.internal.cdo.CDOStore.convertToEMF(CDOStore.java:565) at org.eclipse.emf.internal.cdo.CDOStore.get(CDOStore.java:175) at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateGet(EStoreEObjectImpl.java:247) at org.eclipse.emf.common.util.DelegatingEList.get(DelegatingEList.java:236) at org.eclipse.emf.cdo.tests.FeatureMapTest.testFeatureMaps(FeatureMapTest.java:224) 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:592) 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) ... 18 more
Created attachment 185418 [details] Fix v1 Martin please check if you agree with this...
With Fix v1 two other legacy tests fail ;-(
I'll have a look at it as soon as possible. Could it be that this one is dublicate of bug 302807? At least, it seems, that they are somehow related.
Created attachment 185484 [details] Patch v2 I applied a patch to fix the problem. The problem was that we have more than one representation for NIL. In fact the difference between CDORevisionData.NIL and EStoreEObjectImpl.NIL caused the problem. I am not quite sure whether we could join both to one? Or is this separation needed because revision and store a two separate concepts? Would it make sense to create something like CDOUitl.isNIL which chekcs for the different NIL objects?
(In reply to comment #4) > I am not quite sure whether we could join both to one? Or is this separation > needed because revision and store a two separate concepts? I guess this stems from the time where cdo.common had no EMF dependencies
>I guess this stems from the time where cdo.common had no EMF dependencies This means I should file a bugzilla to join the different NIL values to one object? ;)
You could try to change it with this bug.
All right. I'll have a look how conplex the story is and if it is quite easy to solve I'll come up with a new patch :)
Created attachment 185495 [details] Patch v3 I added the changes. All tests are passing and I was even able to optimize the store a bit. O.k. the improvement might not be countable, but it feels good ;) See whether it is o.k. for you to remove the NIL class.
Committed to HEAD.
Available in R20110608-1407
