Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] custom data type/Class cast exception on notification([CDO] custom data type/Class cast exception on notification)
[CDO] custom data type/Class cast exception on notification [message #1619129] Mon, 16 February 2015 11:01 Go to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
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)



Re: [CDO] custom data type/Class cast exception on notification [message #1619149 is a reply to message #1619129] Mon, 16 February 2015 11:18 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
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)
>
>
>
>


Re: [CDO] custom data type/Class cast exception on notification [message #1619166 is a reply to message #1619149] Mon, 16 February 2015 11:30 Go to previous messageGo to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
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.

David
Re: [CDO] custom data type/Class cast exception on notification [message #1619179 is a reply to message #1619166] Mon, 16 February 2015 11:40 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
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


Re: [CDO] custom data type/Class cast exception on notification [message #1619271 is a reply to message #1619179] Mon, 16 February 2015 13:06 Go to previous messageGo to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
I arrived at the same conclusion by debugging. I will try to investigate. Thanks
Re: [CDO] custom data type/Class cast exception on notification [message #1622076 is a reply to message #1619271] Wed, 18 February 2015 08:43 Go to previous messageGo to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
It works fine with a patch on createPrimitiveNotification method. For my general knowledge, can you tell me on whitch criteria, the cdo server decide to send String instead of primitif type ?
Re: [CDO] custom data type/Class cast exception on notification [message #1622083 is a reply to message #1622076] Wed, 18 February 2015 08:46 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
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 #1622245 is a reply to message #1622083] Wed, 18 February 2015 11:06 Go to previous messageGo to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
How does the server to distinguish EMF standard datatypes from custom ones ?
It's just to understand how it works on server-side Smile I'm using a mem-based server.

By the way, what is the meaning of the server (config.xml file) property supportingEcore ?

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 #1622252 is a reply to message #1622245] Wed, 18 February 2015 11:13 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
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.

> 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):

/**
* @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 #1622421 is a reply to message #1622252] Wed, 18 February 2015 13:37 Go to previous messageGo to next message
David Ponzo is currently offline David PonzoFriend
Messages: 14
Registered: November 2014
Junior Member
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 Smile 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 (Smile 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 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
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


Previous Topic:[EMF Validation] Is parralel Batch Validation supported?
Next Topic:EMF: Pupulating ordered list of &quot;scatterd&quot; items
Goto Forum:
  


Current Time: Sat Aug 17 15:34:03 GMT 2019

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

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

Back to the top