Home » Modeling » EMF » (De)serialize EObjectContainmentEList?
| (De)serialize EObjectContainmentEList? [message #1101440] |
Wed, 04 September 2013 13:12  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
I might be doing s.t. stupid, but it looks like (de)serialization of EObjectContainmentEList is impossible.
I'm looking at the following stack in the debugger:
Array.newArray(Class, int) line: not available [native method]
Array.newInstance(Class<?>, int) line: 52
EObjectContainmentEList<E>(EcoreEList<E>).newData(int) line: 57
EObjectContainmentEList<E>(BasicEList<E>).readObject(ObjectInputStream) line: 760
Seeing that https://bugs.eclipse.org/245014 is still unresolved it looks like good news that BasicEList already has a readObject method, but this seems to be broken for EObjectContainmentEList:
The implementation in ECoreEList.newData(int) expects #dataClass to be initialized, but seeing dataClass being null during deserialization I guess this doesn't work because EClass isn't Serializable, right?
Is this a bug?
Does a workaround exist, e.g., can I define my own subclass of EObjectContainmentEList via the genmodel, or s.t. like that?
best,
Stephan
|
|
| | |
| Re: [RESOLVED] (De)serialize EObjectContainmentEList? [message #1101510 is a reply to message #1101498] |
Wed, 04 September 2013 14:52  |
Ed Merks
Messages: 33146
Registered: July 2009 |
Senior Member |
|
|
Stephan,
I've not given any thought to how bidirectional references are properly
handled by java.io Serialization. It seems problematic in general,
especially for bidirectional references where both sides are
multiplicity > 1; you never know which side gets processed first...
Definitely add a comment to that bugzilla. Probably EcoreEList needs a
more specialized override...
On 04/09/2013 4:37 PM, Stephan Herrmann wrote:
> I should have looked just 2 lines further:
> try
> {
> data = newData(arrayLength);
> }
> catch (Throwable exception)
> {
> data = new Object[arrayLength];
> }
>
> The catch block repairs the immediate problem.
>
> It turns out my problem with ELists was in my own code, sorry for
> false alarm.
>
> FWIW, here's the code I'm using to work around the issue that
> eContainer reverse references are not serialized:
>
> public static void fixContainmentReverseReference(EObject root) {
> EClass clazz = root.eClass();
> InternalEObject myRoot = (InternalEObject) root;
> for (EReference ref : clazz.getEAllContainments()) {
> Object child = root.eGet(ref);
> if (child instanceof EObject) {
> if (child instanceof EObjectImpl) {
> ((EObjectImpl) child).eBasicSetContainer(myRoot,
> ((EObject) child).eClass().getFeatureID(ref), null);
> }
> fixContainmentReverseReference((EObject) child);
> } else if (child instanceof EList<?>) {
> for (EObject childElem : (EList<? extends
> EObject>)child) {
> ((EObjectImpl)
> childElem).eBasicSetContainer(myRoot,
> (childElem).eClass().getFeatureID(ref), null);
> }
> }
> }
> }
>
> Would s.t. along these lines make sense inside EMF? In the context of
> https://bugs.eclipse.org/245014 ?
>
> Stephan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: [RESOLVED] (De)serialize EObjectContainmentEList? [message #1102074 is a reply to message #1102058] |
Thu, 05 September 2013 10:18 |
Ed Merks
Messages: 33146
Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
On 05/09/2013 11:50 AM, Stephan Herrmann wrote:
> Hi Tim (? :) ),
>
> Quote:
>> The question is why are you using Java-Serialization? Wouldn't it be
>> easier your use a BinaryResourceImpl?
>
>
> Yes, life would be easier if we could freely choose.
> In this case EMF objects are part of the session state that the
> application framework chooses to store using Java serialization. Not
> our choice to make.
>
> Regarding BinaryResourceImpl: is it easily possible to use this for
> storing EObjects that have been loaded from some other format (XMI,
> Xtext ...)? Would this preserve cross-references between resources?
Yes, there's even an option so that an XMLResourceImpl can save to
binary format:
/**
* A load or save option that when set to Boolean.TRUE, directs
the resource to produce or consume a {@link BinaryResourceImpl
binary serialization}.
* 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.
* @since 2.7
*/
String OPTION_BINARY = "BINARY";
I'm not sure about Xtext; there you generally want to preserve the exact
original source text...
>
> I'm strongly in favour of using EMF models not only in tooling but
> also in applications, but integrating with Java serialization makes
> this a bumpier road than I had expected.
Yes, Java serialization is in general a little flaky in my opinion...
It's quite unsuitable for long term persistence...
>
> Maybe next time we design an application which uses EMF at runtime
> we'll develop some hybrid serialization: persist EMF models using EMF
> mechanisms, during Java serialization just write an EMF URI into the
> stream and manually resolve this URI during deserialization.
Yes, or perhaps some type of wrapper that serializes the whole
containing resource (like we did for SDO)...
> Has anybody gone this road already?
I don't have much experience with using Java serialization, other than
with SDO, but that's been many years and has been archived...
> For this particular application this idea is probably too late, though.
>
> best,
> Stephan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri May 10 22:19:58 GMT 2024
Powered by FUDForum. Page generated in 0.04453 seconds |
] 
Search
Help
Register
Login
Home
),