Home » Modeling » EMF » [CDO] instance objects and java Serializable
| [CDO] instance objects and java Serializable [message #514372] |
Mon, 15 February 2010 06:14  |
 david varnes
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Hi,
We are using CDO 2.0 with a db backed repository, works great,
thanks very much Eike and team !
We have a requirement to provide a remoted service with a mix
of both CDO and pojo classes. Our default pattern for this is
some variation of Spring remoting, normally httpInvoker. This
requires, of course, that all classes are Serializable. Getting
the marker interface to be carried in the CDO classes is easy
enough, but after doing that I realised that at runtime the
CDO objects do not have any direct member features for the
nativa Java serializer to work with, since all features are
delegated. Obvious enough when you stumble over it ! :-)
So I am sure we are not the first to arrive at this point,
what are the options ? I have dug around in the news archive
and some bugzilla entries.
a. I hope I am missing something obvious and can simply
configure either the Ecore model or the genmodel to
support native java serialization ?
b. Is there some way to invoke standard java serialization
on the CDO EStore that is backing the delegated features ?
I guess it must be available to the serializer at run
time ?
c. Ed's patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014
seems to add serializing and deserializing support to EMF.
Is this just for models with Feature Delegation=NONE ?
Would it work straight up for CDO models ?
d. [maybe OT] Perhaps the easiest path is to avoid native java
serialization completely and find an alternative way to
implement remoting that will work with both pojo and CDO
objects. Again, maybe others have negotiated a successful
path through this ...
e. Extending from d, I see the serialization that CDO-Net4j
uses .. has anyone, or would it be easy to extend this
to support serialization for a generic pojo ?
thanks for any pointers
davidv
|
|
|
| Re: [CDO] instance objects and java Serializable [message #514379 is a reply to message #514372] |
Mon, 15 February 2010 02:10  |
|
Hi David,
Comments below...
Am 15.02.2010 07:14, schrieb david varnes:
> Hi,
> We are using CDO 2.0 with a db backed repository, works great,
> thanks very much Eike and team !
You're welcome ;-)
>
> We have a requirement to provide a remoted service with a mix
> of both CDO and pojo classes. Our default pattern for this is
> some variation of Spring remoting, normally httpInvoker. This
> requires, of course, that all classes are Serializable. Getting
> the marker interface to be carried in the CDO classes is easy
> enough, but after doing that I realised that at runtime the
> CDO objects do not have any direct member features for the
> nativa Java serializer to work with, since all features are
> delegated. Obvious enough when you stumble over it ! :-)
>
> So I am sure we are not the first to arrive at this point,
> what are the options ? I have dug around in the news archive
> and some bugzilla entries.
>
> a. I hope I am missing something obvious and can simply
> configure either the Ecore model or the genmodel to
> support native java serialization ?
AFAIK Java serialization is tightly bound to instance fields, their
types, modifiers, etc. As you outlined above CDOObjects (or other
feature-delegating classes) do not have instance fileds. At least not
for the modeled features. I don't see how enabling serialization for
EObjects in general would help if there's nothing in them that could be
serialized this way.
>
> b. Is there some way to invoke standard java serialization
> on the CDO EStore that is backing the delegated features ?
> I guess it must be available to the serializer at run
> time ?
A CDOStore (CDO's EStore) is pretty much stateless. It delegates all
access to the CDORevisions that are referenced from the CDOObjects:
object.cdoRevision(). These CDORevisions are serializeable, but not in
the Java sense as that would be way too verbose. If you want to try this
mechanism nevertheless, I suggest to look at uses of
CDODataInput.readCDORevision() and CDODataOutput.writeCDORevision().
Note that the "content" of a CDORevision is in some ways not identical
to the content of an EObject. For example reference targets are
represented by CDOIDs rather than actual EObjects.
>
> c. Ed's patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014
> seems to add serializing and deserializing support to EMF.
> Is this just for models with Feature Delegation=NONE ?
> Would it work straight up for CDO models ?
I don't know it but I don't believe it for the reasons given above.
>
> d. [maybe OT] Perhaps the easiest path is to avoid native java
> serialization completely and find an alternative way to
> implement remoting that will work with both pojo and CDO
> objects. Again, maybe others have negotiated a successful
> path through this ...
>
> e. Extending from d, I see the serialization that CDO-Net4j
> uses .. has anyone, or would it be easy to extend this
> to support serialization for a generic pojo ?
Net4j does not care so much about the marshalling/unmarshalling of
objects. In Net4j that is left exclusively to the user-provided protocol
logic (the reason why it is much more compressed than generic formats).
Of course you can use Net4j to *transport* anything you want. You only
have to define how you write to and read from a stream.
Cheers
/Eike
----
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] instance objects and java Serializable [message #514383 is a reply to message #514379] |
Mon, 15 February 2010 07:53 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike, David,
Java offers some specific overrides for de-serialization. See here:
http://java.sun.com/developer/technicalArticles/Programming/ serialization/
it gives some hints, check specifically the writeObject and readObject methods. There is probably more info on the
internet on how to implement these methods in a custom way.
Maybe these serialization methods can be implemented to read/write feature values using the CDO/EMF api.
gr. Martin
Eike Stepper wrote:
> Hi David,
>
> Comments below...
>
>
>
> Am 15.02.2010 07:14, schrieb david varnes:
>> Hi,
>> We are using CDO 2.0 with a db backed repository, works great,
>> thanks very much Eike and team !
> You're welcome ;-)
>
>>
>> We have a requirement to provide a remoted service with a mix
>> of both CDO and pojo classes. Our default pattern for this is
>> some variation of Spring remoting, normally httpInvoker. This
>> requires, of course, that all classes are Serializable. Getting
>> the marker interface to be carried in the CDO classes is easy
>> enough, but after doing that I realised that at runtime the
>> CDO objects do not have any direct member features for the
>> nativa Java serializer to work with, since all features are
>> delegated. Obvious enough when you stumble over it ! :-)
>>
>> So I am sure we are not the first to arrive at this point,
>> what are the options ? I have dug around in the news archive
>> and some bugzilla entries.
>>
>> a. I hope I am missing something obvious and can simply
>> configure either the Ecore model or the genmodel to
>> support native java serialization ?
> AFAIK Java serialization is tightly bound to instance fields, their
> types, modifiers, etc. As you outlined above CDOObjects (or other
> feature-delegating classes) do not have instance fileds. At least not
> for the modeled features. I don't see how enabling serialization for
> EObjects in general would help if there's nothing in them that could be
> serialized this way.
>
>>
>> b. Is there some way to invoke standard java serialization
>> on the CDO EStore that is backing the delegated features ?
>> I guess it must be available to the serializer at run
>> time ?
> A CDOStore (CDO's EStore) is pretty much stateless. It delegates all
> access to the CDORevisions that are referenced from the CDOObjects:
> object.cdoRevision(). These CDORevisions are serializeable, but not in
> the Java sense as that would be way too verbose. If you want to try this
> mechanism nevertheless, I suggest to look at uses of
> CDODataInput.readCDORevision() and CDODataOutput.writeCDORevision().
> Note that the "content" of a CDORevision is in some ways not identical
> to the content of an EObject. For example reference targets are
> represented by CDOIDs rather than actual EObjects.
>
>>
>> c. Ed's patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014
>> seems to add serializing and deserializing support to EMF.
>> Is this just for models with Feature Delegation=NONE ?
>> Would it work straight up for CDO models ?
> I don't know it but I don't believe it for the reasons given above.
>
>>
>> d. [maybe OT] Perhaps the easiest path is to avoid native java
>> serialization completely and find an alternative way to
>> implement remoting that will work with both pojo and CDO
>> objects. Again, maybe others have negotiated a successful
>> path through this ...
>>
>> e. Extending from d, I see the serialization that CDO-Net4j
>> uses .. has anyone, or would it be easy to extend this
>> to support serialization for a generic pojo ?
> Net4j does not care so much about the marshalling/unmarshalling of
> objects. In Net4j that is left exclusively to the user-provided protocol
> logic (the reason why it is much more compressed than generic formats).
> Of course you can use Net4j to *transport* anything you want. You only
> have to define how you write to and read from a stream.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [CDO] instance objects and java Serializable [message #514408 is a reply to message #514383] |
Mon, 15 February 2010 09:07 |
|
Am 15.02.2010 08:53, schrieb Martin Taal:
> Hi Eike, David,
> Java offers some specific overrides for de-serialization. See here:
> http://java.sun.com/developer/technicalArticles/Programming/ serialization/
>
> it gives some hints, check specifically the writeObject and readObject
> methods. There is probably more info on the internet on how to
> implement these methods in a custom way.
> Maybe these serialization methods can be implemented to read/write
> feature values using the CDO/EMF api.
I wonder how referenced objects should be dealt with...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi David,
>>
>> Comments below...
>>
>>
>>
>> Am 15.02.2010 07:14, schrieb david varnes:
>>> Hi,
>>> We are using CDO 2.0 with a db backed repository, works great,
>>> thanks very much Eike and team !
>> You're welcome ;-)
>>
>>>
>>> We have a requirement to provide a remoted service with a mix
>>> of both CDO and pojo classes. Our default pattern for this is
>>> some variation of Spring remoting, normally httpInvoker. This
>>> requires, of course, that all classes are Serializable. Getting
>>> the marker interface to be carried in the CDO classes is easy
>>> enough, but after doing that I realised that at runtime the
>>> CDO objects do not have any direct member features for the
>>> nativa Java serializer to work with, since all features are
>>> delegated. Obvious enough when you stumble over it ! :-)
>>>
>>> So I am sure we are not the first to arrive at this point,
>>> what are the options ? I have dug around in the news archive
>>> and some bugzilla entries.
>>>
>>> a. I hope I am missing something obvious and can simply
>>> configure either the Ecore model or the genmodel to
>>> support native java serialization ?
>> AFAIK Java serialization is tightly bound to instance fields, their
>> types, modifiers, etc. As you outlined above CDOObjects (or other
>> feature-delegating classes) do not have instance fileds. At least not
>> for the modeled features. I don't see how enabling serialization for
>> EObjects in general would help if there's nothing in them that could
>> be serialized this way.
>>
>>>
>>> b. Is there some way to invoke standard java serialization
>>> on the CDO EStore that is backing the delegated features ?
>>> I guess it must be available to the serializer at run
>>> time ?
>> A CDOStore (CDO's EStore) is pretty much stateless. It delegates all
>> access to the CDORevisions that are referenced from the CDOObjects:
>> object.cdoRevision(). These CDORevisions are serializeable, but not
>> in the Java sense as that would be way too verbose. If you want to
>> try this mechanism nevertheless, I suggest to look at uses of
>> CDODataInput.readCDORevision() and CDODataOutput.writeCDORevision().
>> Note that the "content" of a CDORevision is in some ways not
>> identical to the content of an EObject. For example reference targets
>> are represented by CDOIDs rather than actual EObjects.
>>
>>>
>>> c. Ed's patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=245014
>>> seems to add serializing and deserializing support to EMF.
>>> Is this just for models with Feature Delegation=NONE ?
>>> Would it work straight up for CDO models ?
>> I don't know it but I don't believe it for the reasons given above.
>>
>>>
>>> d. [maybe OT] Perhaps the easiest path is to avoid native java
>>> serialization completely and find an alternative way to
>>> implement remoting that will work with both pojo and CDO
>>> objects. Again, maybe others have negotiated a successful
>>> path through this ...
>>>
>>> e. Extending from d, I see the serialization that CDO-Net4j
>>> uses .. has anyone, or would it be easy to extend this
>>> to support serialization for a generic pojo ?
>> Net4j does not care so much about the marshalling/unmarshalling of
>> objects. In Net4j that is left exclusively to the user-provided
>> protocol logic (the reason why it is much more compressed than
>> generic formats). Of course you can use Net4j to *transport* anything
>> you want. You only have to define how you write to and read from a
>> stream.
>>
>> Cheers
>> /Eike
>>
>> ----
>> 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] instance objects and java Serializable [message #514629 is a reply to message #514379] |
Tue, 16 February 2010 06:24 |
david varnes
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Eike,
Thanks for your fast response ...
Eike Stepper wrote:
> Hi David,
>
[snip]
>>
>> We have a requirement to provide a remoted service with a mix
>> of both CDO and pojo classes. Our default pattern for this is
Well, on the way home last night I did have an a-hah moment,
realising that the whole premise of my question was flawed. Just
in case this short cuts a solution for others ..
It is pointless to try and serialize CDO objects for remoting
because of the 'C' in CDO. At the remote end there will be no
CDOView to provide them with lifecycle oxygen. ( I was certainly
not planning to try and remote the session or view).
So the whole question is moot. Of course from this perspective,
an easy way to move forward it to simply remote the CDOIDs of
the cdo objects that need to be remoted, since the CDOID *is*
Serializable.
This of course requires that a CDO session is available at the
remote end for re-hydrating the full CDO objects from their
CDOIDs. Fortunately for our case, this is the case, and was a
quick re-factor, and works very well !!
So, thanks for letting me think out loud :-)
davidv
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 04:33:27 GMT 2024
Powered by FUDForum. Page generated in 0.03319 seconds |
] 
Search
Help
Register
Login
Home
