Hi Ate It's ok :
Loading simple1 Deserialize.. After creation [startIngTrs.processMsg is running : true message:message2 serialize.. Process finished with exit code 0 Thanks Regards, Francis. On Fri, Apr 18, 2014 at 2:12 PM, Ate Douma <[email protected]> wrote: Hi Francis, Thanks for the example test code, it helped me detect a bug in the state machine running status management which I already fixed, see [1]. Can you test and verify this now works for you? (note: you'll have to use SCXML trunk). I've one more comment inline below. Regards, Ate [1] https://issues.apache.org/jira/browse/SCXML-202 On 16-04-14 22:14, [email protected] wrote: Thanks for your reply Ate. I want to serialize/deserialize a SCXML 'session' for this use case : Into a transactional server, a request is processed by a thread. An ID is retrieved from the message, with this ID the server loads a context (from a redis store) and instantiates a new 'Executor' with it's associated SCXML file and saved instance. I'll use invokers to call external functions or new a SCXML 'processor', I don't expect them to still be running after the state machine stabilized. You said : "But then you should not set the statemachine again (after attachInstance) as that will re-initialize the SCInstance itself" so I don't have to do this "executor.setStateMachine(scxml);"because scxml is serialized with the scInstance. But if I need to register a listener (addListener) or if I have custom actions, are they serialized too? No, SCXMLListeners are also not serialized. The reasoning for this is that, like with the Invokers, and all other interface based injected external objects, there is no way to determine and detect what they might end up serializing, if even possible. And they might be referenced themselves by other non-serialized objects which 'reference link' would get borked and broken after de-serialization. So you'll have to re-register listeners again as well. That is just the only save and stable way to do this. Note: the SCXMLListeners are 'registered' on the internal SCXML element id's and not the serialized elements themselves, so if you would not have to re-create SCXMLExecutor, *then* there is no need to re-register anything. In the example I do 'setInitialState(executor, "paused");' because the call to go resets the state and I know that 'paused' is the last state. Of course I want to 'return' in the same state I left off. Without a call of the go function, the state machine seems to be frozen. That was because of the bug I now fixed. AFAIK the example code you provided now 'works'. Thanks, Regards Francis. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
