[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] My experience with ECF
- From: Hallvard Trætteberg <hal@xxxxxxxxxxx>
- Date: Thu, 06 Nov 2014 09:22:25 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Date: Wed, 5 Nov 2014 16:10:16 -0600 (CST)
From: J Langley <jlangley@xxxxxxxxxxxxxxxxx>
One issue that we ran into was that we were using an EClass with EOperations to define the interface that we publish as an OSGi service. Using the default parameters in the genmodel gave us methods that return an EList<EClass> instead of a normal List<Class>. The EList caused problems during serialization, so we wound up regenerating the interface class using the "suppress EMF types" option set to true. We only needed to use this option for the interface classes, not the data types being passed.
Much of our data types were serializable without any needed updates. The problem popped up when we had use the EDataType to bring in other Java types that are not seriailizable. We wound up writing a single serialization helper class that packs an EObject into a resource and then serialized the resource. The opposite happens on the receive side. It was a lot of work to capture all of the referenced objects as well, since they have to be packed into the resource as well (in reverse order). This was the bane of my existence for a few weeks. We updated the Class.javajet template to have each class implement serializable and added the writeObject and readObject to turn around and call our Serialization helper.
Much of the debugging included writing the serialization resource to a temp file on writeObject and readObject so we could get an idea of what data was being included. Also - don't forget to find the properties that govern the timeout values and update them to give you enough time to step through code if needed.
Another note that I still do not understand - there were unit tests that ran successfully in a single process (writing to a byte stream and reading an object back from the byte stream) that failed when run cross process through a socket. There may be some static registration of objects happening in the Resource class that allowed things to pass. I did not have enough time to fully investigate.
Thanks for sharing you experiences! From my own experience, things can
be very tricky if not handled using the right mechanism. I know lots of
people are using various serializations (XML/XMI, binary, json) of EMF
data in distributed and web-oriented systems, so I'm surprised if OSGi
remote services makes it particularly difficult.
I'll update this thread as I remember more issues.
Please, do. And it would be great if the root of the problems could be
identified, so that people are not scared from using EMF in general,