Home » Modeling » EMF » Readable serialization format for EMF/GWT
|
Re: Readable serialization format for EMF/GWT [message #755479 is a reply to message #755465] |
Tue, 08 November 2011 15:52 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Csaba,<br>
<br>
Comments below.<br>
<br>
On 08/11/2011 4:26 PM, Csaba Koncz wrote:
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">Hi
all,
<br>
<br>
I have been using parts of the GWT port of EMF for a while and I
really love working with it. I would like to congratulate the
authors for this piece of software.
<br>
</blockquote>
I'm glad it's proving useful.<br>
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">
<br>
The part I am not using is the server side integration. Instead, I
have two versions of generated code from the same Ecore model: one
for GWT and one for the IDE environment. </blockquote>
I think the Cloudsmith people were using one code base for both.
There's not much different in the model code anyway and the
annotations don't prevent it from running in a regular JVM (I
think); the item provider stuff is quite different though...<br>
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">The
client tries to keep the server side model in sync by posting
ChangeDescriptions (created with the new copyAndReverse method). </blockquote>
Yes, the Cloudsmith folks are relying on that as well.<br>
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">Everything
works nicely with one exception: the only resource available on
the GWT side is BinaryResourceImpl, so I can not monitor what
messages are actually sent to the server. </blockquote>
There's not much in GWT to support XML properly.<br>
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">
This makes debugging the client-server communication a bit
difficult, e.g. finding that
ChangeRecorder.setRecordingTransientFeatures(false); does not have
any effect took me some time.
<br>
<br>
My question: is there a non-binary serialization format like (XMI
or JSON) that I could use in this scenario?
<br>
</blockquote>
No, but are you really having trouble deserializing on the server
side? Binary is so much more compact and faster. Note that
XMIResourceImpl can now support binary, XML, and XMI serialization,
given the right options. So it should be easy on the server to read
with an XMIResourceImpl using this option to read the binary stream.<br>
<br>
<blockquote><small> /**</small><br>
<small> * A load or save option that when set to Boolean.TRUE,
directs the resource to produce or consume a {@link
BinaryResourceImpl binary serialization}.</small><br>
<small> * By default, unless a {@link
BinaryResourceImpl#OPTION_VERSION version option} is specified,
a {@link Version#VERSION_1_1 version 1.1} serialization will be
produced.</small><br>
<small> * @since 2.7</small><br>
<small> */</small><br>
<small> String OPTION_BINARY = "BINARY";</small><br>
</blockquote>
And then you can use resource.save(System.out, null) to print it out
as XML or XMI for debugging purposes.<br>
<blockquote cite="mid:j9bguv$esg$1@news.eclipse.org" type="cite">
<br>
Best wishes,
<br>
Csaba
<br>
<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Readable serialization format for EMF/GWT [message #755652 is a reply to message #755465] |
Wed, 09 November 2011 08:40 |
Tom H Messages: 139 Registered: July 2009 |
Senior Member |
|
|
Interesting, I have been looking at the org.eclipse.emf.gwt project myself.
I had a problem where every so often trying to access the resource would result in a NUllPointer when iterating the featureID if a structural feature.
So if I extracted the client side binary to a file, should I be able to open it in a generated editor? I mean if I dump the datastore blob binary into a file.
[Updated on: Wed, 09 November 2011 08:55] Report message to a moderator
|
|
|
Re: Readable serialization format for EMF/GWT [message #755930 is a reply to message #755479] |
Thu, 10 November 2011 09:01 |
Csaba Koncz Messages: 49 Registered: July 2009 |
Member |
|
|
Hi Ed,
Thank you for the advice. I tried it out and although it did not work immediately, I managed to get it work and proved really useful (found some errors in my model like accidental non-containment references, referenced objects that I forgot to add to their container).
When using the BinaryResourceImpl I was not aware of these, but XMIResourceImpl issued warnings when dumping it to System.out.
(The problem with reading the binary stream was that XMLResourceImpl, after loading EObjectInputStream, tries to load the extrinsic ID map, which was not produced by BinaryResourceImpl. I tricked this by appending a compressedInt of value 0 to the end of the byte array produced by the client).
The original problem I had on the server side was with deserializing ChangeDescriptions only because they contained changes referring to transient features. As I invoked setRecordingTransientFeatures(false) on the ChangeRecorder, I was not suspecting this, until finally looked into the code and saw that this flag is ignored. So this was easily solved by subclassing ChangeRecorder so that it really ignores transient features, but having a readable serialization format from the beginning would have maybe saved me some time spent in the debugger.
As to not using the GWT binaries on the server: currently it has no advantage, but maybe later if I need to use some other stuff like EMF Compare/Merge or a persistence solution, then maybe I will be better off with the "regular" EMF. Am I right?
Csaba
|
|
|
Re: Readable serialization format for EMF/GWT [message #755935 is a reply to message #755930] |
Thu, 10 November 2011 09:07 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Csaba,
Comments below.
On 10/11/2011 10:01 AM, Csaba Koncz wrote:
> Hi Ed,
>
> Thank you for the advice. I tried it out and although it did not work
> immediately, I managed to get it work and proved really useful (found
> some errors in my model like accidental non-containment references,
> referenced objects that I forgot to add to their container).
> When using the BinaryResourceImpl I was not aware of these, but
> XMIResourceImpl issued warnings when dumping it to System.out.
>
> (The problem with reading the binary stream was that XMLResourceImpl,
> after loading EObjectInputStream, tries to load the extrinsic ID map,
> which was not produced by BinaryResourceImpl. I tricked this by
> appending a compressedInt of value 0 to the end of the byte array
> produced by the client).
Oh, that's kind of nasty. :-( Could you please open a bugzilla about
this. Not sure how to address that given it's something that only
XMLResourceImpl will know how to produce and consume... Perhaps the
reader should be more tolerant of it being absent...
>
> The original problem I had on the server side was with deserializing
> ChangeDescriptions only because they contained changes referring to
> transient features. As I invoked setRecordingTransientFeatures(false)
> on the ChangeRecorder, I was not suspecting this, until finally looked
> into the code and saw that this flag is ignored. So this was easily
> solved by subclassing ChangeRecorder so that it really ignores
> transient features, but having a readable serialization format from
> the beginning would have maybe saved me some time spent in the debugger.
I see.
>
> As to not using the GWT binaries on the server: currently it has no
> advantage, but maybe later if I need to use some other stuff like EMF
> Compare/Merge or a persistence solution, then maybe I will be better
> off with the "regular" EMF. Am I right?
Yes, the full EMF runtime is more powerful. E.g., you might want XML
serialization or other full EMF runtime support...
> Csaba
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 25 20:43:43 GMT 2024
Powered by FUDForum. Page generated in 0.03097 seconds
|