Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: 1. Start a CDO Server connected to an empty a db. 2. Start a client that creates data containing Enum values. 3. Close the client session. 4. Stop the CDO Server. 5. Start the CDO Server again 6. Start a client and try reading previous created data. Stephane. More information: CDO build : 2.0.0M6 Here is the stack trace I got : org.eclipse.net4j.signal.RemoteException: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128) at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:466) at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:53) at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55) at org.eclipse.net4j.signal.Signal.doInput(Signal.java:317) at org.eclipse.net4j.signal.Indication.execute(Indication.java:49) at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237) at org.eclipse.net4j.signal.Signal.run(Signal.java:145) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doWriteValue(CDOTypeImpl.java:303) at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$ObjectType.writeValue(CDOTypeImpl.java:432) at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDOFeatureValue(CDODataOutputImpl.java:251) at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision.writeValues(AbstractCDORevision.java:643) at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision.write(AbstractCDORevision.java:162) at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:154) at org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionIndication.responding(LoadRevisionIndication.java:158) at org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndication.responding(CDOServerIndication.java:119) at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:96) at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285) at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65) at org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndication.execute(CDOReadIndication.java:36)
I cannot reproduce this through MEMStore. So I believed it is a DBStore problem. I will remove the dependency that I added through 268663. DBstore doesn`t pass the testcase EnumTest.
Yes it's bug linked to db store. I have to test again but I'm thinking, I fix the bug. I will attach patches asap.
Created attachment 129820 [details] CDOTypeImpl.ENUM modification
Created attachment 129821 [details] convertToEMF changes
Created attachment 129822 [details] Changes in the insertAttributes method
After additional tests, it seems the bug is fixed ! I modify different files : 1) CDOTypeImpl.ENUM implementation to transfer enum values as Integer. 2) CDOStore#convertToEMF(..) method to handle Enum value. Indeed, as Enum values are transfered as Integer, it is not possible to instantiate the right ENumerator in the CDOTypeImpl (for read operations from a client to a server). Hence, the convertToEMF method seemed to be the right place to convert the enum value as integer in its right Enumerator because at this moment the feature is known thus the feature etype too. 3) PreparedStatementJDBCDelegate#doInsertAttributes(..) to also handle org.eclipse.emf.common.util.Enumerator as EMF generated classes that implement this interface for Enums. At the moment, only EEnumLiteral are handled but it is not enough to manage all cases : first cdo server start with no data, cdo server re-start with existing data, etc. Unfortunately, I don't have CVS access at office :( Hence, I can not make a real patch as you might expect. Nevertheless, I've attached 3 files regarding the 3 classes I modified with only the modified part. I put a TODO task named : // TODO FIX CDO to help you retrieving the code. I do hope it can help you to fix this bug. Stephane.
hi Stephane, Thank you for the patch. In the refactoring of CDOType(268663) we planned to not convert the data until serialization. That means do as less as possible in convertToEMF and ConverttoCDO should not deal with that. We will only convert them at serialization time.(To be more optimal) In M5, Enum was Integer like you just did... we`ve put it back to String for simplicity of the code so it willl be easier to change. After EclipseCon, I will try to come up with a patch for 268663. After we could see how your patch fits in there. Does it sounds good ?
Hi Simon, It sounds great to be able to deal with its own types. To be able to instantiate an Enum value from the integer as serialization time (when a client is requesting the value from the server), we might need to add a new argument to CDOType.readValue(CDODataInput in) to have the feature that provides a way to know the Enum type and so the ability to instantiate the right enum instance from the integer At the end, I am not a CDO expert, the patches I made, allow me to work with the 2.0.0 M6. If in M7, Enums are handled in a different manner that do not raise Exceptions, that's great to me :) Stephane.
Is it possible that you revalidate this problem without the patch after bug 254698 is resolved?
Absolutely, I can test without the patch. I suppose I should get the latest code from the HEAD ? Which plug-ins am I supposed to update ?
All :P
What's the status of this bug? There is some code (in the enum-TypeMapping) which is marked as sort of "temporary", but which seems to fix the CCE-issue. Is there anything left to do? Else, this bug should be marked RESOLVED FIXED.
I think this issue was fixed. RESOLVING FIXED. Stephane, please re-open if you still encounter problems...
Fix available in CDO 2.0.0M7
Generally available.