commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: SCXML2 Serialization
Date Fri, 18 Apr 2014 12:12:17 GMT
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

I've one more comment inline below.

Regards, Ate


On 16-04-14 22:14, 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:
For additional commands, e-mail:

View raw message