Community
Participate
Working Groups
I my model I have an attribute which is a list of int[], EList<int[]>. int[] is defined as a custom data type in the model. As soon as I try to add anything to the list I get a ClassCastException. java.lang.ClassCastException: org.eclipse.emf.internal.cdo.revision.CDOListWithElementProxiesImpl cannot be cast to java.lang.String ERROR at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.convertToEMF(CDOTypeImpl.java:592) at org.eclipse.emf.internal.cdo.CDOStore.convertToEMF(CDOStore.java:581) at org.eclipse.emf.internal.cdo.CDOStore.get(CDOStore.java:176) at org.eclipse.emf.internal.cdo.CDOStore.isSet(CDOStore.java:194) at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.isSet(EStoreEObjectImpl.java:161) at org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl.addUnique(DelegatingNotifyingListImpl.java:280) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307) I can also trigger the error calling "eIsSet" for the same attribute.
The same error also happens when there is a list of enums. java.lang.ClassCastException: org.eclipse.emf.cdo.internal.common.revision.CDOListImpl cannot be cast to java.lang.Integer ERROR at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$23.convertToEMF(CDOTypeImpl.java:478) at org.eclipse.emf.internal.cdo.CDOStore.convertToEMF(CDOStore.java:581) at org.eclipse.emf.internal.cdo.CDOStore.get(CDOStore.java:176) at org.eclipse.emf.internal.cdo.CDOStore.isSet(CDOStore.java:194) at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.isSet(EStoreEObjectImpl.java:161) at org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl.addUnique(DelegatingNotifyingListImpl.java:280) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307)
(In reply to comment #0) > I my model I have an attribute which is a list of int[], EList<int[]>. int[] is > defined as a custom data type in the model. Does that mean you're not using the built-in EInt with -1 as upper bound? > java.lang.ClassCastException: > org.eclipse.emf.internal.cdo.revision.CDOListWithElementProxiesImpl cannot be > cast to java.lang.String Is it possible that you send me your model and a smal test (privately if you want)? Alternatively you could try to write a small test case in our test framework. See the other JUnit tests for examples.
No, it is not an EInt with upper bound -1. It's a double array. What I have is a data type defined as <eClassifiers xsi:type="ecore:EDataType" name="IntArray" instanceClassName="int[]"/> and an attribute in a class defined as <eStructuralFeatures xsi:type="ecore:EAttribute" name="attrName" unique="false" upperBound="-1" eType="#//IntArray"/> This int[] is just an example. Any custom data type fails. The stack trace in the follow-up comment comes from an enum definition. <eClassifiers xsi:type="ecore:EEnum" name="TYPES"> <eLiterals name="onetype"/> <eLiterals name="anothertype="1"/> <eLiterals name="moretype" value="2"/> </eClassifiers> This is used in an attribute of a class. <eStructuralFeatures xsi:type="ecore:EAttribute" name="typeList" unique="false" upperBound="-1" eType="#//TYPES"/>
I added this to model5.ecore: <eClassifiers xsi:type="ecore:EClass" name="GenListOfIntArray"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="elements" upperBound="-1" eType="#//IntArray"/> </eClassifiers> <eClassifiers xsi:type="ecore:EDataType" name="IntArray" instanceClassName="int[]"/> I added Bugzilla_322218_Test: public void testAddElementToCustomTypedList() throws Exception { CDOSession session = openSession(); CDOTransaction transaction = session.openTransaction(); CDOResource resource = transaction.createResource("/r1"); msg("Fill and commit a resource"); GenListOfIntArray object = getModel5Factory().createGenListOfIntArray(); resource.getContents().add(object); transaction.commit(); msg("Add int[] elements"); object.getElements().add(new int[] { 1, 2, 3, 4, 5 }); object.getElements().add(new int[] { 10, 20, 30, 40, 50 }); transaction.commit(); session.close(); } Committed to R3_0_maintenance
The test passes and I can not reproduce your problem. Are you sure that no other "special" things apply to your scenario? Closing as WORKSFORME. Please reopen if you think I misunderstood something or if you can reproduce the problem.
It could very well be something "special" about our model, but I don't know what to look for. Is there some more information I can dig out from the debugger? The problem I have looks very similar to bug 322185.
(In reply to comment #6) > It could very well be something "special" about our model, but I don't know > what to look for. Is there some more information I can dig out from the > debugger? Hard to give general debugging advice that you don't already know. Nothing special I think. > The problem I have looks very similar to bug 322185. Okay, I'll add tests with an unsettable list of a custom type. If it turns out that bug 322185 is similar, I'll fix it there...
(In reply to comment #1) > The same error also happens when there is a list of enums. > I am experiencing this problem too (reported at http://www.eclipse.org/forums/index.php/t/209341/). Here are some steps to reproduce the problem using Eclipse: - Open a CDO session in Eclipse - Register the attached test case 'test.ecore' - Open a transaction and create a resource if needed - Edit the resource. Right-click -> New Root -> http://test.ecore -> Sample object - Edit the "Sample attribute" value of the newly created object - Add anything in the feature column and confirm The ClassCastException is thrown in CDOTypeImpl.convertToEMF(), line 478, but the error is probably in the caller CDOStore.convertToEMF(). In the latter, the value of feature.isMany() is true (as expected) and index is EStore.NO_INDEX. Also, since I do not commit the changes made in the resource I do not see the connection with bug 322185.
Created attachment 196189 [details] List of EEnum test case
Moving all open problem reports to 4.0
Maybe the following fact can shed some light: I could re-create the problem with the following Test-Scenario: EClass: SomeClass containing the following EAttributes and their specific differences AttributeName ORDERED TRANSIENT UNIQUE UNSETTABLE ErrorOccurs? fails F F T T yes works T F T F no orderedFALSE F F T T no unsettableTRUE T F T T YES each of them with lower bound 0 upper bound -1 being of EType "self created EENum". So the problem seems to occure due to the Property "unsettable" being set to true, at least with this property set to false the following error is not occuring: org.eclipse.emf.cdo.internal.common.revision.CDOListWithElementProxiesImpl cannot be cast to java.lang.Integer
sorry, the line orderedFALSE F F T T no should be orderedFALSE F F T F no
Created attachment 214757 [details] Screenshot for test.ecore I simply can't reproduce this in 4.1. I've tried the attached test.ecore without problems (see attached screenshot). I've also added 14 test cases: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/bugzilla/Bugzilla_322218_Test.java None of them fails.
Please try to write a test case like the ones I referred to above. If I can reproduce it it's more likely that I can fix it.
I also tried the attached test.ecore with 4.0, same result: no problems. I believe that you do have a problem but I must resolve as worksforme again, until I can reproduce the problem. Please also try with the latest sources or builds and reopen this bug if needed.
Is it possible that you're using legacy objects? Can you please provide a *complete* stack trace, ideally against a latest CDO 4.1?
Reopening because of a vague idea...
Change in CDOStoreImpl.convertToEMF() from if (feature.isMany() && index != EStore.NO_INDEX) to if (feature.isMany()) { if (index == EStore.NO_INDEX) { return value; }
Fixed in 4.1 first. Please let me know if this works for you and if a port to 4.0 is desired. commit d57f1d7713c7fbfbc023df2fae808bf50af3e857
The error, as documented, is not occuring with my testcase in 4.1 anymore :) Thanks a lot! A port to 4.0 would be very nice!! All the best!
(In reply to comment #20) > The error, as documented, is not occuring with my testcase in 4.1 anymore :) > Thanks a lot! You're welcome. > A port to 4.0 would be very nice!! Ok, I'll see what I can do tomorrow. Otherwise it won't make it before next Tuesday.
Port to 4.0 via bug 378283.
Closing.
