You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by te...@free.fr on 2014/04/16 15:07:04 UTC

SCXML2 Serialization

Hi all,

I would like to know the best practice to serialize/deserialize SCXML fsm.

I do this during the creation of the SCXML executor, scInstace is the serialized context:

            List<CustomAction> customActions = new ArrayList<CustomAction>();
            CustomAction ca =
                    new CustomAction("http://my.custom-actions.domain/CUSTOM1",
                            "hello", Hello.class);
            customActions.add(ca);

            JexlEvaluator evaluator = new JexlEvaluator();

            try {
                scxml = SCXMLReader.read(StopWatch.class.getClassLoader().

            } catch (Exception e) {
                e.printStackTrace();
                throw e;
            }


            executor = null;
            try {
                executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());

                if (scInstance != null) {
                    // serialized context use it
                    executor.attachInstance(scInstance);
                    executor.registerInvokerClass("x-test", DummyInvoker.class);
                    executor.setStateMachine(scxml);
                    executor.go();
                    setInitialState(executor, "paused");
                } else {
                    // new context
                    Context rootContext = new JexlContext();
                    rootContext.set("var1", "value1");
                    executor.registerInvokerClass("x-test", DummyInvoker.class);
                    executor.setStateMachine(scxml);
                    executor.setRootContext(rootContext);
                    executor.go();
                }

            } catch (ModelException me) {
                // Executor initialization failed, because the
                // state machine specified has inconsistencies
                me.printStackTrace();
            }

I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?

Thanks
Francis.



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: SCXML2 Serialization

Posted by Ate Douma <at...@douma.nu>.
Hi Francis,

There are a few things not right or needed in your approach below.
I've provided comments inline.

On 16-04-14 15:07, tendaf@free.fr wrote:
> Hi all,
>
> I would like to know the best practice to serialize/deserialize SCXML fsm.
>
> I do this during the creation of the SCXML executor, scInstace is the serialized context:
>
>              List<CustomAction> customActions = new ArrayList<CustomAction>();
>              CustomAction ca =
>                      new CustomAction("http://my.custom-actions.domain/CUSTOM1",
>                              "hello", Hello.class);
>              customActions.add(ca);
>
>              JexlEvaluator evaluator = new JexlEvaluator();
>
>              try {
>                  scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
>
>              } catch (Exception e) {
>                  e.printStackTrace();
>                  throw e;
>              }
>
>
>              executor = null;
>              try {
>                  executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());

While you can recreate SCXMLExecutor each time, this is not the intended usage.
The SCXMLExecutor holds the external event queue. If you are using Invokers, and 
you *do* in your example, then these might still be (kept) 'running' while the 
state machine itself is currently stabilized. So after a return from go() or 
triggerEvent(). And these invokers might send back events into the external 
queue for further processing. So then you should keep hold of the SCXMLExecutor 
instance, across serialization/deserialization of the SCInstance.
If you don't use Invokers, or don't expect them to still be running after the 
state machine stabilized (which might be the case in your example?) then I guess 
recreating the SCXMLExecutor is fine. But then you should not set the 
statemachine again (after attachIstance) as that will re-initialize the 
SCInstance itself. Same goes for calling go() again or otherwise re-initializing 
the current state. What would be the point of serializing in that case anyway?
Note also, the statemachine is automatically serialized together with the 
SCInstance, so you actually don't need to set it again.

>
>                  if (scInstance != null) {
>                      // serialized context use it
>                      executor.attachInstance(scInstance);
>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>                      executor.setStateMachine(scxml);
this shouldn't be done as it will re-initialize the SCInstance state
>                      executor.go();
this does the same, so definitely shouldn't be done either, because this way 
there is no 'state' retained from what you serialized before
>                      setInitialState(executor, "paused");
same goes for this: if you re-attach the instance, I assume you would want to 
'return' in the same state you left off, right?

>                  } else {
>                      // new context
>                      Context rootContext = new JexlContext();
>                      rootContext.set("var1", "value1");
>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>                      executor.setStateMachine(scxml);
>                      executor.setRootContext(rootContext);
>                      executor.go();
This initialization part is fine
>                  }
>
>              } catch (ModelException me) {
>                  // Executor initialization failed, because the
>                  // state machine specified has inconsistencies
>                  me.printStackTrace();
>              }
>
> I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?
See comments above. You're almost good but especially need to think about the 
Invoker use-cases and if that might require you to keep hold of the 
SCXMLExecutor instance.

Regards, Ate

>
> Thanks
> Francis.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: SCXML2 Serialization

Posted by Woonsan Ko <wo...@yahoo.com>.

On Wednesday, April 16, 2014 9:57 AM, Ate Douma <at...@douma.nu> wrote:

Hi Woonsan,
>
>On 16-04-14 15:49, Woonsan Ko wrote:
>> Hi Francis,
>>
>> I think the best practices are to serialize either o.a.c.s.SCXMLExecutor [1] or o.a.c.s.model.SCXML instances. Both cases are well-maintained in test code. [2]
>Actually, since the last milestone SCXMLExecutor no longer is serializable :)
>See also https://issues.apache.org/jira/browse/SCXML-197
>
>I still need to provide updated documentation for this, but the SCXMLTestHelper 
>[2] class has been (and had to be) updated for this changed usage.
>
>> In your case, you can probably (de)serialize SCXMLExecutor instance directly to store/load the execution context.
>> Also, as far as I can see, SCXMLExecutor doesn't provide #(at|de)tachInstance() methods and I don't think it would do even later because SCInstance doesn't necessarily have full information about the current execution context.
>> So, please (de)serialize the SCXMLExecutor instance instead.
>
>You need to update to the latest milestone 1 or trunk, then you'll see the new 
>attach/detach instance features ;)

Ah, sorry. I haven't updated the code for a while. My comment was based on outdated information then..


Thanks,

Woonsan


>
>>
>> Cheers,
>>
>> Woonsan
>>
>> [1] http://commons.apache.org/proper/commons-scxml/faq.html#serializability
>> [2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml2/SCXMLTestHelper.java
>>
>>
>>
>> On Wednesday, April 16, 2014 9:07 AM, "tendaf@free.fr" <te...@free.fr> wrote:
>>
>> Hi all,
>>>
>>> I would like to know the best practice to serialize/deserialize SCXML fsm.
>>>
>>> I do this during the creation of the SCXML executor, scInstace is the serialized context:
>>>
>>>              List<CustomAction> customActions = new ArrayList<CustomAction>();
>>>              CustomAction ca =
>>>                      new CustomAction("http://my.custom-actions.domain/CUSTOM1",
>>>                              "hello", Hello.class);
>>>              customActions.add(ca);
>>>
>>>              JexlEvaluator evaluator = new JexlEvaluator();
>>>
>>>              try {
>>>                  scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
>>>
>>>              } catch (Exception e) {
>>>                  e.printStackTrace();
>>>                  throw e;
>>>              }
>>>
>>>
>>>              executor = null;
>>>              try {
>>>                  executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());
>>>
>>>                  if (scInstance != null) {
>>>                      // serialized context use it
>>>                      executor.attachInstance(scInstance);
>>>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>>>                      executor.setStateMachine(scxml);
>>>                      executor.go();
>>>                      setInitialState(executor, "paused");
>>>                  } else {
>>>                      // new context
>>>                      Context rootContext = new JexlContext();
>>>                      rootContext.set("var1", "value1");
>>>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>>>                      executor.setStateMachine(scxml);
>>>                      executor.setRootContext(rootContext);
>>>                      executor.go();
>>>                  }
>>>
>>>              } catch (ModelException me) {
>>>                  // Executor initialization failed, because the
>>>                  // state machine specified has inconsistencies
>>>                  me.printStackTrace();
>>>              }
>>>
>>> I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?
>>>
>>> Thanks
>>> Francis.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>
>>>
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>For additional commands, e-mail: user-help@commons.apache.org
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: SCXML2 Serialization

Posted by Ate Douma <at...@douma.nu>.
Hi Woonsan,

On 16-04-14 15:49, Woonsan Ko wrote:
> Hi Francis,
>
> I think the best practices are to serialize either o.a.c.s.SCXMLExecutor [1] or o.a.c.s.model.SCXML instances. Both cases are well-maintained in test code. [2]
Actually, since the last milestone SCXMLExecutor no longer is serializable :)
See also https://issues.apache.org/jira/browse/SCXML-197

I still need to provide updated documentation for this, but the SCXMLTestHelper 
[2] class has been (and had to be) updated for this changed usage.

> In your case, you can probably (de)serialize SCXMLExecutor instance directly to store/load the execution context.
> Also, as far as I can see, SCXMLExecutor doesn't provide #(at|de)tachInstance() methods and I don't think it would do even later because SCInstance doesn't necessarily have full information about the current execution context.
> So, please (de)serialize the SCXMLExecutor instance instead.

You need to update to the latest milestone 1 or trunk, then you'll see the new 
attach/detach instance features ;)

>
> Cheers,
>
> Woonsan
>
> [1] http://commons.apache.org/proper/commons-scxml/faq.html#serializability
> [2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml2/SCXMLTestHelper.java
>
>
>
> On Wednesday, April 16, 2014 9:07 AM, "tendaf@free.fr" <te...@free.fr> wrote:
>
> Hi all,
>>
>> I would like to know the best practice to serialize/deserialize SCXML fsm.
>>
>> I do this during the creation of the SCXML executor, scInstace is the serialized context:
>>
>>              List<CustomAction> customActions = new ArrayList<CustomAction>();
>>              CustomAction ca =
>>                      new CustomAction("http://my.custom-actions.domain/CUSTOM1",
>>                              "hello", Hello.class);
>>              customActions.add(ca);
>>
>>              JexlEvaluator evaluator = new JexlEvaluator();
>>
>>              try {
>>                  scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
>>
>>              } catch (Exception e) {
>>                  e.printStackTrace();
>>                  throw e;
>>              }
>>
>>
>>              executor = null;
>>              try {
>>                  executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());
>>
>>                  if (scInstance != null) {
>>                      // serialized context use it
>>                      executor.attachInstance(scInstance);
>>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>>                      executor.setStateMachine(scxml);
>>                      executor.go();
>>                      setInitialState(executor, "paused");
>>                  } else {
>>                      // new context
>>                      Context rootContext = new JexlContext();
>>                      rootContext.set("var1", "value1");
>>                      executor.registerInvokerClass("x-test", DummyInvoker.class);
>>                      executor.setStateMachine(scxml);
>>                      executor.setRootContext(rootContext);
>>                      executor.go();
>>                  }
>>
>>              } catch (ModelException me) {
>>                  // Executor initialization failed, because the
>>                  // state machine specified has inconsistencies
>>                  me.printStackTrace();
>>              }
>>
>> I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?
>>
>> Thanks
>> Francis.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: SCXML2 Serialization

Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Francis,

I think the best practices are to serialize either o.a.c.s.SCXMLExecutor [1] or o.a.c.s.model.SCXML instances. Both cases are well-maintained in test code. [2]
In your case, you can probably (de)serialize SCXMLExecutor instance directly to store/load the execution context.
Also, as far as I can see, SCXMLExecutor doesn't provide #(at|de)tachInstance() methods and I don't think it would do even later because SCInstance doesn't necessarily have full information about the current execution context.
So, please (de)serialize the SCXMLExecutor instance instead.

Cheers,

Woonsan

[1] http://commons.apache.org/proper/commons-scxml/faq.html#serializability
[2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml2/SCXMLTestHelper.java



On Wednesday, April 16, 2014 9:07 AM, "tendaf@free.fr" <te...@free.fr> wrote:
 
Hi all,
>
>I would like to know the best practice to serialize/deserialize SCXML fsm.
>
>I do this during the creation of the SCXML executor, scInstace is the serialized context:
>
>            List<CustomAction> customActions = new ArrayList<CustomAction>();
>            CustomAction ca =
>                    new CustomAction("http://my.custom-actions.domain/CUSTOM1",
>                            "hello", Hello.class);
>            customActions.add(ca);
>
>            JexlEvaluator evaluator = new JexlEvaluator();
>
>            try {
>                scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
>
>            } catch (Exception e) {
>                e.printStackTrace();
>                throw e;
>            }
>
>
>            executor = null;
>            try {
>                executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());
>
>                if (scInstance != null) {
>                    // serialized context use it
>                    executor.attachInstance(scInstance);
>                    executor.registerInvokerClass("x-test", DummyInvoker.class);
>                    executor.setStateMachine(scxml);
>                    executor.go();
>                    setInitialState(executor, "paused");
>                } else {
>                    // new context
>                    Context rootContext = new JexlContext();
>                    rootContext.set("var1", "value1");
>                    executor.registerInvokerClass("x-test", DummyInvoker.class);
>                    executor.setStateMachine(scxml);
>                    executor.setRootContext(rootContext);
>                    executor.go();
>                }
>
>            } catch (ModelException me) {
>                // Executor initialization failed, because the
>                // state machine specified has inconsistencies
>                me.printStackTrace();
>            }
>
>I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?
>
>Thanks
>Francis.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>For additional commands, e-mail: user-help@commons.apache.org
>
>
>
>