[jira] [Comment Edited] (SCXML-239) Groovy Context lose sync after serialize/deserialize of SCinstance

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SCXML-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076654#comment-15076654 ] 

Ate Douma edited comment on SCXML-239 at 1/2/16 8:52 PM:
---------------------------------------------------------

Thanks for reporting this!
Clearly a bug and it took me a while to figure out what goes wrong.

The problem lies in the custom GroovyContext serialization handling, for which I added (SCXML-186) overriding readObject and writeObject methods.
Within the readObject method, Groovy objects stored in the context variables their deserialization class name needs to be dynamically resolved.
For that purpose an extra extended ByteInputStream is used with an override for the resolveClass() method.
Long story short, while this technically is working correct, it goes wrong if the variables contain an object *also* otherwise deserialized by the 'main' ObjectInputStream, in which case this object will be deserialized *twice* (separate instances) as these two ObjectInputStreams don't know about each other :( 
And this occurs with the SCInstance Status instance variable which also is referenced from the protected variables within the SCXMLSystemContext.
Hence, after SCInstance deserialization these two Statuses are no longer the same, causing the problem you detected.

For now, I'll fix this 'quick and dirty', by no longer using an language specific Context (e.g. GroovyContext) for this protected SCXMLSystemContext internal context, nor the (default) root Context.
Those two contexts don't need to be, nor IMO should be, language specific anyway.
With these fixes the SCXMLSystemContext internal context will just use the default (de)serializing ObjectInputStream and thus no longer create two 'disconnected' Status objects. 

However, this still leaves the door open for GroovyContext deserialization problems if/when its variables contain an object also otherwise referenced by SCInstance.

I've created SCXML-247 which will provide a more resilient solution. 


was (Author: adouma):
Thanks for reporting this!
Clearly a bug and it took me a while to figure out what goes wrong.

The problem lies in the custom GroovyContext serialization handling, for which I added (SCXML-186) overriding readObject and writeObject methods.
Within the readObject method, Groovy objects stored in the context variables their deserialization class name needs to be dynamically resolved.
For that purpose an extra extended ByteInputStream is used with an override for the resolveClass() method.
Long story short, while this technically is working correct, it goes wrong if the variables contain an object *also* otherwise deserialized by the 'main' ObjectInputStream, in which case this object will be deserialized *twice* (separate instances) as these two ObjectInputStreams don't know about each other :( 
And this occurs with the SCInstance Status instance variable which also is referenced from the protected variables within the SCXMLSystemContext.
Hence, after SCInstance deserialization these two Statuses are no longer the same, causing the problem you detected.

For now, I'll fix this 'quick and dirty', by no longer using an language specific Context (e.g. GroovyContext) for this protected SCXMLSystemContext internal context, nor the (default) root Context.
Those two contexts don't need to be, nor IMO should be, language specific anyway.
With these fixes the SCXMLSystemContext internal context will just use the default (de)serializing ObjectInputStream and thus no longer create two 'disconnected' Status objects. 

However, this still leaves the door open for GroovyContext deserialization problems if/when its variables contain an object also otherwise referenced by SCInstance.
The only way I can see how to fix this proper is to provide dedicated serialization and deserialization (static) methods on SCInstance itself in which we can use our own extended ObjectInputStream/ObjectOutputStream classes which then also can be leveraged within the GroovyContext to dynamically resolve a Groovy class.
I'll create a separate issue to implement that as a new feature. 
 

> Groovy Context lose sync after serialize/deserialize of SCinstance
> ------------------------------------------------------------------
>
>                 Key: SCXML-239
>                 URL: https://issues.apache.org/jira/browse/SCXML-239
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Goran Kadnar
>            Assignee: Ate Douma
>             Fix For: 2.0
>
>         Attachments: testNOK.trc, testOK.trc, test_case.7z
>
>
> Groovy Context lose sync after serialize/deserialize SC instance
> Steps to reproduce issue:
> 	1. detach SC instance
> 	2. serialize SC instance
> 	3. deserialize SC instance
> 	4. attach SC instance
> Result:
> 	Groovy context loose sync, and afterwards In('state') condition is not working properly



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)