commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject SCXML2 Serialization
Date Fri, 18 Apr 2014 13:33:46 GMT
Hi Ate

It's ok :

Loading simple1
After creation [startIngTrs.processMsg is running : true

Process finished with exit code 0


On Fri, Apr 18, 2014 at 2:12 PM, Ate Douma <> 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

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'.


Regards Francis.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message