[jira] [Resolved] (SCXML-202) State machine running status must be kept and maintained by SCInstance across serialization and deserialization

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

     [ https://issues.apache.org/jira/browse/SCXML-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved SCXML-202.
-----------------------------

    Resolution: Fixed

> State machine running status must be kept and maintained by SCInstance across serialization and deserialization
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: SCXML-202
>                 URL: https://issues.apache.org/jira/browse/SCXML-202
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>            Priority: Minor
>             Fix For: 2.0
>
>
> As was discovered and reported by Francis Tenda on the commons users@ list, currently it isn't possible to serialize/de-serialize a state machine instance (SCInstance) without keeping hold on the (same) SCXMLExecutor and its embedded SCXMLExecutorContext.
> While the use-cases for re-creating a new SCXMLExecutor/SCXMLExecutorContext every time after deserializing an SCInstance might be limited, as you cannot have/keep running Invokers and will have to re-configure the Evaluator, Dispatcher, ErrorReporter as well as any SCXMLListeners every time then, it still should be possible.
> The problem is that the SCXMLExecutorContext currently manages the state machine running status and never get 'triggered' to set it (back) to running after re-attaching a SCInstance. With as effect that any subsequent firing of events will be ignored.
> The running status logically 'belongs' to the state machine itself, and thus it currently is wrongly managed.
> I'll fix this by moving this status property into SCInstance instead, which thereby should also fix the test example Francis Tenda provided on the list.



--
This message was sent by Atlassian JIRA
(v6.2#6252)