[
https://issues.apache.org/jira/browse/SCXML-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076654#comment-15076654
]
Ate Douma commented on SCXML-239:
---------------------------------
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)
