Skip to main content


Eclipse Community Forums

      Home
Home » Modeling » EMF » [CDO] CDO Model Corruption
[CDO] CDO Model Corruption [message #511688] Tue, 02 February 2010 09:39 Go to next message
Eclipse UserFriend
Hi,

I imported two models on a CDO 2.0 server. Those models (let us call them A and B) are consistent
with two different metamodels MMA and MMB (A with MMA, B with MMB). Some EClasses of MMA and MMB
have the same name.

When i execute my program (a client of the CDO server), I get the following error popup:
An error has occurred. See error log for mode details.
org.eclipse.net4j.signal.RemoteException.
java.lang.ClassCastException : java.lang.Boolean cannot be cast to java.lang.String

If I launch the navigator view, and then load the model, I get the following error:
A protocol problem occurred in CDOSession after 1 attempt.

This error occurs regularly, with a ratio of about one out of ten times. Once I get this
problem, it seems like the only way to fix it is to delete my database and restart the CDO server.

So I have two questions:
1. Could the fact that I have 2 meta model which define a class with the same names cause problems on CDO?
(note that this happen even if the property "QualifiedName" is set to "true").
If so, is there a workaround for this problem? Did I forget to configure something?

For refrence, here is a excerpt from my cdo-server.xml :
<store type="db">

<mappingStrategy type="horizontal">
<property name="qualifiedNames" value="true"/>
<property name="toManyReferences" value="ONE_TABLE_PER_REFERENCE"/>
<property name="toOneReferences" value="LIKE_ATTRIBUTES"/>
</mappingStrategy>

<dbAdapter name="postgresql"/>

<dataSource class="org.postgresql.ds.PGSimpleDataSource"
url="jdbc:postgresql://localhost:5432/cdo"
databaseName="cdo"
user="postgres"
password="XX"/>
</store>

Here is the stack trace I get at runtime :

[ERROR] [Ljava.lang.StackTraceElement;
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:483)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:399)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:387)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:87)
at java.lang.ClassLoader.loadClass(Unknown Source)
...
org.eclipse.net4j.signal.RemoteException: java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteEx ception(RequestWithConfirmation.java:128)
at org.eclipse.net4j.signal.SignalProtocol.handleRemoteExceptio n(SignalProtocol.java:494)
at org.eclipse.net4j.signal.RemoteExceptionIndication.indicatin g(RemoteExceptionIndication.java:53)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
...
Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.wri teValue(CDOTypeImpl.java:590)
at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:271)
at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:661)

Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #511826 is a reply to message #511688] Wed, 03 February 2010 01:48 Go to previous messageGo to next message
Eclipse UserFriend
Hi Gaëtan,

Comments below...


Gaetan schrieb:
> Hi,
> I imported two models on a CDO 2.0 server. Those models (let us call
> them A and B) are consistent
> with two different metamodels MMA and MMB (A with MMA, B with MMB).
> Some EClasses of MMA and MMB
> have the same name.
>
> When i execute my program (a client of the CDO server), I get the
> following error popup:
> An error has occurred. See error log for mode details.
It would probably help to give us the complete stack trace.

> org.eclipse.net4j.signal.RemoteException.
> java.lang.ClassCastException : java.lang.Boolean cannot be cast to
> java.lang.String
>
> If I launch the navigator view, and then load the model, I get the
> following error: A protocol problem occurred in CDOSession after 1
> attempt.
>
> This error occurs regularly, with a ratio of about one out of ten
> times. Once I get this
> problem, it seems like the only way to fix it is to delete my database
> and restart the CDO server.
>
> So I have two questions:
> 1. Could the fact that I have 2 meta model which define a class with
> the same names cause problems on CDO?
Generally yes.

> (note that this happen even if the property "QualifiedName" is set to
> "true").
Then no, this should enable you to store models with the same EClass name.

> If so, is there a workaround for this problem? Did I forget to
> configure something?
>
> For refrence, here is a excerpt from my cdo-server.xml : <store
> type="db">
>
> <mappingStrategy type="horizontal">
> <property name="qualifiedNames" value="true"/>
> <property name="toManyReferences"
> value="ONE_TABLE_PER_REFERENCE"/>
> <property name="toOneReferences"
> value="LIKE_ATTRIBUTES"/>
> </mappingStrategy>
>
> <dbAdapter name="postgresql"/>
>
> <dataSource class="org.postgresql.ds.PGSimpleDataSource"
> url="jdbc:postgresql://localhost:5432/cdo"
> databaseName="cdo"
> user="postgres"
> password="XX"/>
> </store>
>
> Here is the stack trace I get at runtime :
Ah, here it is ;-)

> [ERROR] [Ljava.lang.StackTraceElement;
> java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
> at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl
> assInternal(BundleLoader.java:483)
> at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl
> ass(BundleLoader.java:399)
> at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl
> ass(BundleLoader.java:387)
> at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa
> dClass(DefaultClassLoader.java:87)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> ...
> org.eclipse.net4j.signal.RemoteException:
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> java.lang.String
> at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteEx
> ception(RequestWithConfirmation.java:128)
> at org.eclipse.net4j.signal.SignalProtocol.handleRemoteExceptio
> n(SignalProtocol.java:494)
> at org.eclipse.net4j.signal.RemoteExceptionIndication.indicatin
> g(RemoteExceptionIndication.java:53)
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati
> on.java:55)
> ...
> Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be
> cast to java.lang.String
> at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.wri
> teValue(CDOTypeImpl.java:590)
> at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri
> teCDOFeatureValue(CDODataOutputImpl.java:271)
> at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision.
> writeValues(AbstractCDORevision.java:661)
The trace indicates a problem with custom EDataTypes. IIRC we fixed
several issues in this area. Can you please try in this order:

1) Checkout the latest sources from the 2.0 maintenance branch and try
with those (Let me know if you need pointers)
2) Checkout HEAD or use yesterdays M5 build from the helios repository
and try with CDO 3.0

If that shows that your particular issue has not yet been solved, we'll
investigate further.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDO Model Corruption [message #511867 is a reply to message #511826] Wed, 03 February 2010 04:57 Go to previous messageGo to next message
Eclipse UserFriend
Eike Stepper wrote on Wed, 03 February 2010 01:48

The trace indicates a problem with custom EDataTypes. IIRC we fixed
several issues in this area. Can you please try in this order:

1) Checkout the latest sources from the 2.0 maintenance branch and try
with those (Let me know if you need pointers)
2) Checkout HEAD or use yesterdays M5 build from the helios repository
and try with CDO 3.0

If that shows that your particular issue has not yet been solved, we'll
investigate further.



Eike,

thanks for your answer.

Our current platform is Ganymede / CDO 2.0, so we are already using the latest 2.0 maintenance branch.

Porting our code base to Galileo would involve a significant effort; we will try to extract a snippet sufficient to reproduce this error on Galileo / CDO 3.0, though.

Should we fail in this attempt and be stuck with Ganymede / CDO 2.0, do you have any workaround to suggest, considering that we are already using QualifiedName=true?

Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #511873 is a reply to message #511867] Wed, 03 February 2010 05:04 Go to previous messageGo to next message
Eclipse UserFriend
Gaetan schrieb:
> Eike Stepper wrote on Wed, 03 February 2010 01:48
>> The trace indicates a problem with custom EDataTypes. IIRC we fixed
>> several issues in this area. Can you please try in this order:
>>
>> 1) Checkout the latest sources from the 2.0 maintenance branch and try
>> with those (Let me know if you need pointers)
>> 2) Checkout HEAD or use yesterdays M5 build from the helios repository
>> and try with CDO 3.0
>>
>> If that shows that your particular issue has not yet been solved, we'll
>> investigate further.
>
>
> Eike,
>
> thanks for your answer.
>
> Our current platform is Ganymede / CDO 2.0, so we are already using
> the latest 2.0 maintenance branch.
No, that's way behind the latest state in CVS.

>
> Porting our code base to Galileo would involve a significant effort;
> we will try to extract a snippet sufficient to reproduce this error on
> Galileo / CDO 3.0, though.
>
> Should we fail in this attempt and be stuck with Ganymede / CDO 2.0,
> do you have any workaround to suggest, considering that we are already
> using QualifiedName=true?
Let's discuss that after the failure :P

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDO Model Corruption [message #511901 is a reply to message #511873] Wed, 03 February 2010 06:19 Go to previous messageGo to next message
Eclipse UserFriend
Eike, Gaetan,

I believe the cast problem was somehow related with issues in the
PostgreSQL support, that we fixed lately.
Re: [CDO] CDO Model Corruption [message #514042 is a reply to message #511688] Fri, 12 February 2010 04:41 Go to previous messageGo to next message
Eclipse UserFriend
Eike, Victor,

Thanks for your answer.

Following your advice, I have checked out the latest CDO versions from CVS, and I have ran my code on:
- CDO 2.0 (the latest 2.0 maintenance branch version on CVS) with Mysql and Postgres,
- CD0 3.0 (the latest version Head branch) with Mysql and Postgres,

I still very regularly reproduce the error I am struggling with, either on CDO 2.0 or 3.0:

- on the CDO server I get: 
java.lang.Integer cannot be cast to java.lang.String
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.writeValue(CDOTypeImpl.java:589)
at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDOFeatureValue(CDODataOutputImpl.java:296)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeValues(BaseCDORevision.java:640)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.write(BaseCDORevision.java:182)
at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:211)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRevision(RevisionInfo.java:183)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeResult(RevisionInfo.java:134)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevisionsIndication.responding(LoadRevisionsIndication.java:186)
at org.eclipse.emf.cdo.server.internal.net4j.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:281)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIndication.execute(CDOReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


- on the CDO client I get: 
[Ljava.lang.StackTraceElement;
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:483)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:399)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:387)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.net4j.util.io.ExtendedIOUtil$ClassLoaderClassResolver.resolveClass(ExtendedIOUtil.java:231)
at org.eclipse.net4j.util.io.ExtendedIOUtil$3.resolveClass(ExtendedIOUtil.java:163)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readArray(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.eclipse.net4j.util.io.ExtendedIOUtil.readObject(ExtendedIOUtil.java:177)
at org.eclipse.net4j.util.io.ExtendedIOUtil.readObject(ExtendedIOUtil.java:131)
at org.eclipse.net4j.util.io.ExtendedDataInputStream.readObject(ExtendedDataInputStream.java:46)
at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:46)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:311)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
org.eclipse.net4j.signal.RemoteException: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128)
at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:495)
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:311)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.writeValue(CDOTypeImpl.java:589)
at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDOFeatureValue(CDODataOutputImpl.java:296)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeValues(BaseCDORevision.java:640)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.write(BaseCDORevision.java:182)
at org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:211)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRevision(RevisionInfo.java:183)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeResult(RevisionInfo.java:134)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevisionsIndication.responding(LoadRevisionsIndication.java:186)
at org.eclipse.emf.cdo.server.internal.net4j.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:281)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIndication.execute(CDOReadIndication.java:36)
... 5 more

Do you have any hint which would help me solving this?

BTW, both links to developpers PSF file on http://wiki.eclipse.org/CDO_Source_Installation seems broken ("unknown location" error on viewcvs page).

Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #514060 is a reply to message #514042] Fri, 12 February 2010 00:44 Go to previous messageGo to next message
Eclipse UserFriend
Am 12.02.2010 10:41, schrieb Gaetan:
> Eike, Victor,
> Thanks for your answer.
>
> Following your advice, I have checked out the latest CDO versions from
> CVS, and I have ran my code on: - CDO 2.0 (the latest 2.0
> maintenance branch version on CVS) with Mysql and Postgres,
> - CD0 3.0 (the latest version Head branch) with Mysql and Postgres,
>
> I still very regularly reproduce the error I am struggling with,
> either on CDO 2.0 or 3.0:
> - on the CDO server I get: java.lang.Integer cannot be cast to
> java.lang.String
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.String
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.wri teValue(CDOTypeImpl.java:589)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:296)
>
Can you set a breakpoint here and tell which feature is causing the problem?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> at
> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writ eValues(BaseCDORevision.java:640)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writ e(BaseCDORevision.java:182)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:211)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRe vision(RevisionInfo.java:183)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRe sult(RevisionInfo.java:134)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevis ionsIndication.responding(LoadRevisionsIndication.java:186)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServer Indication.responding(CDOServerIndication.java:119)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:281)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIn dication.execute(CDOReadIndication.java:36)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> - on the CDO client I get: [Ljava.lang.StackTraceElement;
> java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:483)
>
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:399)
>
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:387)
>
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:87)
>
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at
> org.eclipse.net4j.util.io.ExtendedIOUtil$ClassLoaderClassRes olver.resolveClass(ExtendedIOUtil.java:231)
>
> at
> org.eclipse.net4j.util.io.ExtendedIOUtil$3.resolveClass(Exte ndedIOUtil.java:163)
>
> at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
> at java.io.ObjectInputStream.readClassDesc(Unknown Source)
> at java.io.ObjectInputStream.readArray(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
> at java.io.ObjectInputStream.readSerialData(Unknown Source)
> at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.readObject(Unknown Source)
> at
> org.eclipse.net4j.util.io.ExtendedIOUtil.readObject(Extended IOUtil.java:177)
>
> at
> org.eclipse.net4j.util.io.ExtendedIOUtil.readObject(Extended IOUtil.java:131)
>
> at
> org.eclipse.net4j.util.io.ExtendedDataInputStream.readObject (ExtendedDataInputStream.java:46)
>
> at
> org.eclipse.net4j.signal.RemoteExceptionIndication.indicatin g(RemoteExceptionIndication.java:46)
>
> at
> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:311)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> org.eclipse.net4j.signal.RemoteException:
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.String
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteEx ception(RequestWithConfirmation.java:128)
>
> at
> org.eclipse.net4j.signal.SignalProtocol.handleRemoteExceptio n(SignalProtocol.java:495)
>
> at
> org.eclipse.net4j.signal.RemoteExceptionIndication.indicatin g(RemoteExceptionIndication.java:53)
>
> at
> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:311)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be
> cast to java.lang.String
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$25.wri teValue(CDOTypeImpl.java:589)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:296)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writ eValues(BaseCDORevision.java:640)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writ e(BaseCDORevision.java:182)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:211)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRe vision(RevisionInfo.java:183)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.writeRe sult(RevisionInfo.java:134)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevis ionsIndication.responding(LoadRevisionsIndication.java:186)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServer Indication.responding(CDOServerIndication.java:119)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:281)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIn dication.execute(CDOReadIndication.java:36)
>
> ... 5 more
>
> Do you have any hint which would help me solving this?
>
> BTW, both links to developpers PSF file on
> http://wiki.eclipse.org/CDO_Source_Installation seems broken ("unknown
> location" error on viewcvs page).
>
> Regards,
> Gaëtan.
Re: [CDO] CDO Model Corruption [message #514071 is a reply to message #514042] Fri, 12 February 2010 06:00 Go to previous messageGo to next message
Eclipse UserFriend
Hi Gaetan,

see some comments below:

Gaetan escribió:
> Following your advice, I have checked out the latest CDO versions from
> CVS, and I have ran my code on: - CDO 2.0 (the latest 2.0
> maintenance branch version on CVS) with Mysql and Postgres,
> - CD0 3.0 (the latest version Head branch) with Mysql and Postgres,
>
> I still very regularly reproduce the error I am struggling with, either
> on CDO 2.0 or 3.0:
> - on the CDO server I get: java.lang.Integer cannot be cast to
> java.lang.String
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.String
> at
> Do you have any hint which would help me solving this?

That seems odd, could you provide information about your model?

> BTW, both links to developpers PSF file on
> http://wiki.eclipse.org/CDO_Source_Installation seems broken ("unknown
> location" error on viewcvs page).

Eike is working to automate all the source installation using
Buckminster, so the old development scripts have been deprecated.

You can still access that PSF file through:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/deprecated/develop/setup/psf/pserver/.boots trap.psf?root=Modeling_Project&view=co

but soon a new tutorial for source installation will be published.

Cheers,
Re: [CDO] CDO Model Corruption [message #514074 is a reply to message #511901] Fri, 12 February 2010 06:11 Go to previous messageGo to next message
Eclipse UserFriend
Am 03.02.2010 12:19, schrieb Víctor Roldán Betancort:
> Eike, Gaetan,
>
> I believe the cast problem was somehow related with issues in the
> PostgreSQL support, that we fixed lately.
I think in the other post Gaetan mentioned that he tried with HEAD...

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDO Model Corruption [message #514122 is a reply to message #514074] Fri, 12 February 2010 08:52 Go to previous messageGo to next message
Eclipse UserFriend
Eike, Victor,

As you suggested, I have set a "ClassCastException" breakpoint in the server code, which led to the following observation.

The model feature where the problem occurs is of an Integer type, but the CDO code handling it directly casts from Object to String : 

public void writeValue(CDODataOutput out, Object value) throws IOException
{
  out.writeString((String)value);
}


Replacing this code by the following one fixed my problem: 

public void writeValue(CDODataOutput out, Object value) throws IOException
{
  out.writeString(String.valueOf(value));
}


Is my analysis correct? If so, would you be so kind as to consider patching CDO branches with this fix?

Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #514169 is a reply to message #514122] Fri, 12 February 2010 11:50 Go to previous messageGo to next message
Eclipse UserFriend
Am 12.02.2010 14:52, schrieb Gaetan:
> Eike, Victor,
> As you suggested, I have set a "ClassCastException" breakpoint in the
> server code, which led to the following observation.
>
> The model feature where the problem occurs is of an Integer type, but
> the CDO code handling it directly casts from Object to String :
The question is, why does CDO choose this partuclar CDOType. Which one
is it exactly? STRING or CUSTOM?
Please also paste in here the part of your ecore file that defines this
feature.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> public void writeValue(CDODataOutput out, Object value) throws
> IOException
> {
> out.writeString((String)value);
> }
>
>
> Replacing this code by the following one fixed my problem:
>
> public void writeValue(CDODataOutput out, Object value) throws
> IOException
> {
> out.writeString(String.valueOf(value));
> }
>
>
> Is my analysis correct? If so, would you be so kind as to consider
> patching CDO branches with this fix?
No, the problem is elsewhere.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDO Model Corruption [message #514184 is a reply to message #514169] Fri, 12 February 2010 12:46 Go to previous messageGo to next message
Eclipse UserFriend
> Eike, Victor,
> As you suggested, I have set a "ClassCastException" breakpoint in the
> server code, which led to the following observation.
>
> The model feature where the problem occurs is of an Integer type, but
> the CDO code handling it directly casts from Object to String :
>The question is, why does CDO choose this partuclar CDOType. Which one
>is it exactly? STRING or CUSTOM?
>Please also paste in here the part of your ecore file that defines this

Preview of my model: 
      <parent xsi:type="XX:Element">
        <source xsi:type="XX:IntType" value="0"/>    
        <target xsi:type="XX:XXType" name="XX"/>
      </parent>

Preview of my meta model:
<eClassifiers xsi:type="ecore:EClass" name="IntType">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="value" ordered="false" unique="false" lowerBound="1" eType="/1/Integer"/>
</eClassifiers>

<ecore:EPackage name="PrimitiveTypes" nsURI="XXPrimitiveTypes" nsPrefix="XX">
<eClassifiers xsi:type="ecore:EDataType" name="Integer" instanceClassName="int"/>
</ecore:EPackage>


Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #514198 is a reply to message #514184] Fri, 12 February 2010 14:02 Go to previous messageGo to next message
Eclipse UserFriend
Am 12.02.2010 18:46, schrieb Gaetan:
>> Eike, Victor,
>> As you suggested, I have set a "ClassCastException" breakpoint in the
>> server code, which led to the following observation.
>>
>> The model feature where the problem occurs is of an Integer type, but
>> the CDO code handling it directly casts from Object to String :
>> The question is, why does CDO choose this partuclar CDOType. Which one
>> is it exactly? STRING or CUSTOM?
>> Please also paste in here the part of your ecore file that defines this
>
> Preview of my model:
> <parent xsi:type="XX:Element">
> <source xsi:type="XX:IntType" value="0"/> <target xsi:type="XX:XXType"
> name="XX"/>
> </parent>
>
> Preview of my meta model:
>
> <eClassifiers xsi:type="ecore:EClass" name="IntType">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="value"
> ordered="false" unique="false" lowerBound="1" eType="/1/Integer"/>
I talked to Ed and we think that looks strange. Do you have more than
one top-level EPackage in your ecore resource?

Please try again with standard models, i.e. one top-level package per
model, ideally no nested packages (but CDO should support the latter).

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> </eClassifiers>
>
> <ecore:EPackage name="PrimitiveTypes" nsURI="XXPrimitiveTypes"
> nsPrefix="XX">
> <eClassifiers xsi:type="ecore:EDataType" name="Integer"
> instanceClassName="int"/>
> </ecore:EPackage>
>
>
> Regards,
> Gaëtan.
Re: [CDO] CDO Model Corruption [message #515938 is a reply to message #514198] Mon, 22 February 2010 04:59 Go to previous messageGo to next message
Eclipse UserFriend
Eike,

Indeed, modifying our metamodel so that only one EPackage was at its root fixed our problem.

We would be interested in understanding in greater details what you mean by "standard models", though. Are models with multiple root packages erroneous from an EMF point of view? Or are they simply bad practices that you chose not to support in CDO?

We had noticed that those metamodels were hard to use in genmodel tools, but EMF manipulates XMI models conforming to them just fine.

Regards,
Gaëtan.
Re: [CDO] CDO Model Corruption [message #515960 is a reply to message #515938] Mon, 22 February 2010 05:57 Go to previous messageGo to next message
Eclipse UserFriend
Hi Gaëtan,

Nothing in EMF creates models with multiple root packages. I think
they're just bad practice.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 22.02.2010 10:59, schrieb Gaetan:
> Eike,
>
> Indeed, modifying our metamodel so that only one EPackage was at its
> root fixed our problem.
>
> We would be interested in understanding in greater details what you
> mean by "standard models", though. Are models with multiple root
> packages erroneous from an EMF point of view? Or are they simply bad
> practices that you chose not to support in CDO?
>
> We had noticed that those metamodels were hard to use in genmodel
> tools, but EMF manipulates XMI models conforming to them just fine.
>
> Regards,
> Gaëtan.
Re: [CDO] CDO Model Corruption [message #515980 is a reply to message #515960] Mon, 22 February 2010 06:54 Go to previous message
Eclipse UserFriend
Gaëtan,

Yes, they're definitely a bad idea.


Eike Stepper wrote:
> Hi Gaëtan,
>
> Nothing in EMF creates models with multiple root packages. I think
> they're just bad practice.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 22.02.2010 10:59, schrieb Gaetan:
>> Eike,
>>
>> Indeed, modifying our metamodel so that only one EPackage was at its
>> root fixed our problem.
>>
>> We would be interested in understanding in greater details what you
>> mean by "standard models", though. Are models with multiple root
>> packages erroneous from an EMF point of view? Or are they simply bad
>> practices that you chose not to support in CDO?
>>
>> We had noticed that those metamodels were hard to use in genmodel
>> tools, but EMF manipulates XMI models conforming to them just fine.
>>
>> Regards,
>> Gaëtan.
Previous Topic:Supporting dynamic/runtime models, should I use the EMF dynamic editor?
Next Topic:bidirectional cross references
Goto Forum:
  


Current Time: Thu Sep 11 01:21:35 EDT 2025

Powered by FUDForum. Page generated in 0.09961 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly