|
| Re: [CDO] custom data type/Class cast exception on notification [message #1619149 is a reply to message #1619129] |
Mon, 16 February 2015 11:18   |
|
Hi David,
You're setting the Instance Type Name of your custom data type to "double". What's the point in defining a custom
serialization of a primitive type?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 16.02.2015 um 12:01 schrieb David Ponzo:
> Hi.
>
> 1) I have created an ecore model where I have defined a custom data type :
> ->MyDouble :
> - Default Value : 0.0
> - Instance Type Name : double
> - Name : MyDouble
> - Serializable : true
> -->ExtendedMetaData
> - References :
> - Source : http:///org.eclipse/emf/ecore/util/ExtendedMetaData
> ----> baseType
> - Key : baseType
> - Value : http://www.w3.org/2001/XMLSchema#double
>
>
> 2) I have created an attribut in the same model and I have applied this custom datatype to it
> 3) I Have create an application with CDO. The client just display the value of the attribut.
> 4) On the server side I change the value the attribut.
>
> On the client side , during the notification I got the following exception :
>
>
> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number
> at
> org.eclipse.emf.internal.cdo.object.CDONotificationBuilder.createPrimitiveNotification(CDONotificationBuilder.java:353)
> at org.eclipse.emf.internal.cdo.object.CDONotificationBuilder.createNotification(CDONotificationBuilder.java:312)
> at org.eclipse.emf.internal.cdo.object.CDONotificationBuilder.visit(CDONotificationBuilder.java:167)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDOSetFeatureDeltaImpl.accept(CDOSetFeatureDeltaImpl.java:74)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.accept(CDORevisionDeltaImpl.java:359)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.accept(CDORevisionDeltaImpl.java:349)
> at org.eclipse.emf.internal.cdo.object.CDONotificationBuilder.buildNotification(CDONotificationBuilder.java:91)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.sendDeltaNotifications(CDOViewImpl.java:1013)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:879)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1710)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
> at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:78)
> at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:70)
> at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:209)
>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] custom data type/Class cast exception on notification [message #1619179 is a reply to message #1619166] |
Mon, 16 February 2015 11:40 |
|
Am 16.02.2015 um 12:30 schrieb David Ponzo:
> Hi Eike, thank for this quick reply.
>
> I have reduce the scope of the problem in the topic I writed. In fact this datatype contain additionnal information
> that we use for databinding validation(such as "minInclusive", ....), but those informations are not usefull for the
> problem I expose.
> I have reproduce the problem with this scope.
Not sure what you mean by "reduced the scope".
CDO can currently not deal with custom data types that have a primitive instance type. I imagine there could by a
solution by enhancing one of the two (or both) methods:
CDONotificationBuilder.createNotification(int, EStructuralFeature, Object, Object, int)
CDONotificationBuilder.createPrimitiveNotification(int, EStructuralFeature, Class<?>, Object, Object)
Would you like to investigate that with your example?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
|
| Re: [CDO] custom data type/Class cast exception on notification [message #1622421 is a reply to message #1622252] |
Wed, 18 February 2015 13:37 |
 David Ponzo
Messages: 14
Registered: November 2014 |
Junior Member |
|
|
Eike Stepper wrote on Wed, 18 February 2015 11:13Am 18.02.2015 um 12:06 schrieb David Ponzo:
> How does the server to distinguish EMF standard datatypes from custom ones ?
> It's just to understand how it works on server-side  I'm using a mem-based server.
Each repository maintains a package registry and knows everything about the used models.
Hence, if the server knows everything on the used meta-model, it could retrieve easiliy if a custom datatype refers to a primitive type (from Instance Type Name) as the ones defined by the Ecore model datatypes (EDouble, EInt, ...).
Instead, I understand, you have explicit code in a cdo server that behaves in a different way based on EcorePackage.Literals.EDOUBLE etc... ?
Could you please point me where it is coded in the cdo server ?
Is it possible to enhance the default cdo server behavior to generate proper notifications based on instance type name from a datatype instead of EMF pre-defined datatypes ?
Either you modifiy the cdo server ( or offer the possibility to add this behavior in extending the CDO server ?
> By the way, what is the meaning of the server (config.xml file) property supportingEcore ?
That property is deprecated (see org.eclipse.emf.cdo.server.IRepository.Props):
Thanks for the tip.
/**
* @since 4.0
* @deprecated As of 4.2 instances of Ecore are always supported (on demand).
*/
@Deprecated
public static final String SUPPORTING_ECORE = "supportingEcore";
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> David.
>
> Eike Stepper wrote on Wed, 18 February 2015 08:46
>> Am 18.02.2015 um 09:43 schrieb David Ponzo:
>> > It works fine with a patch on createPrimitiveNotification method.
>> Perfect. Please contribute your changes!
>>
>> > For my general knowledge, can you tell me on whitch criteria, the cdo server decide to send String instead of
>> primitif > type ?
>> IIRC., Strings are always transfered for custom EDataTypes.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] custom data type/Class cast exception on notification [message #1622483 is a reply to message #1622421] |
Wed, 18 February 2015 14:34 |
|
Am 18.02.2015 um 14:37 schrieb David Ponzo:
> Eike Stepper wrote on Wed, 18 February 2015 11:13
>> Am 18.02.2015 um 12:06 schrieb David Ponzo:
>> > How does the server to distinguish EMF standard datatypes from custom ones ?
>> > It's just to understand how it works on server-side :) I'm using a mem-based server.
>> Each repository maintains a package registry and knows everything about the used models.
>>
>> Hence, if the server knows everything on the used meta-model, it could retrieve easiliy if a custom datatype refers
>> to a primitive type (from Instance Type Name) as the ones defined by the Ecore model datatypes (EDouble, EInt, ...).
>> Instead, I understand, you have explicit code in a cdo server that behaves in a different way based on
>> EcorePackage.Literals.EDOUBLE etc... ?
>> Could you please point me where it is coded in the cdo server ?
I don't think that the server is related here. Only the EMF notifications emitted by the CDO client need to be changed.
I pointed you to the two methods that need to be changed. The casts, e.g., (Number), need to be smarter.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02471 seconds
] 
Search
Help
Register
Login
Home
