Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 18 Apr 2014 12:02:15 +0000 (UTC)
From: "Ate Douma (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12709249.1397822202935.138361.1397822535135@arcas>
In-Reply-To: <JIRA.12709249.1397822202935@arcas>
References: <JIRA.12709249.1397822202935@arcas>
Subject: [jira] [Resolved] (SCXML-202) State machine running status must be
 kept and maintained by SCInstance across serialization and deserialization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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)