SCXML: context thinks it is in no state at all in onentry of non atomic states.

["R.C. Hoekstra" <r....@erasmusmc.nl>]

Hi all at scxml.



In my project I found some behavior which I regarded as unexpected, but maybe I'm overlooking something. In non-atomic states action execution the engine reports to be in no state at all.



I made a test Action class which only does one thing: it prints the result of SCXMLExecutor.getStatus().getAllStates() in a listing to StdOut.



Consider the following simple scxml file:



<state id="entry">

   <transition event="to.test" target="1"/>

</state>



<state id="1">

   <onentry><my:printStates/></onentry>

</state>



This shows the following output:

entering entry

exiting entry

   my prints 1 state: "1"

entering 1



Placing the onentry in an atomic substate like this:



<state id="1">

   <state id="1.1">

        <onentry><my:printStates/></onentry>

   </state>

</state>



shows the following output:

entering entry

exiting entry

entering 1

    my prints 2 states: 1 and 1.1

entering 1.1





However, placing the onentry in the parent of that atomic substate like this:



<state id="1">

    <onentry><my:printStates/></onentry>

    <state id="1.1" />

</state>



gives a result which I hadn't expected:



entering entry

exiting entry

   my prints 0 states

entering 1

entering 1.1



Here, the action reports that the engine is in NO STATE AT ALL.

I can see that the action is always executed before the listener reports it's onentry (of which I'm not sure if it's weird or not), but nevertheless it always reports correctly the states it belongs to. Except when the action is executed on a non-atomic state -> then it believes to be in 0 states.



This looks to me like inconsistent, and thus a bug, or am I overlooking some logic?



Test classes are available at request.



best regards, Rinke

Re: SCXML: context thinks it is in no state at all in onentry of non atomic states.

[Ate Douma <at...@douma.nu>]

On 02-09-14 23:23, R.C. Hoekstra wrote:
> Hi all at scxml.
>
>
>
> In my project I found some behavior which I regarded as unexpected, but maybe I'm overlooking something. In non-atomic states action execution the engine reports to be in no state at all.
>
>
>
> I made a test Action class which only does one thing: it prints the result of SCXMLExecutor.getStatus().getAllStates() in a listing to StdOut.
>
>
>
> Consider the following simple scxml file:
>
>
>
> <state id="entry">
>
>     <transition event="to.test" target="1"/>
>
> </state>
>
>
>
> <state id="1">
>
>     <onentry><my:printStates/></onentry>
>
> </state>
>
>
>
> This shows the following output:
>
> entering entry
>
> exiting entry
>
>     my prints 1 state: "1"
>
> entering 1
>
>
>
> Placing the onentry in an atomic substate like this:
>
>
>
> <state id="1">
>
>     <state id="1.1">
>
>          <onentry><my:printStates/></onentry>
>
>     </state>
>
> </state>
>
>
>
> shows the following output:
>
> entering entry
>
> exiting entry
>
> entering 1
>
>      my prints 2 states: 1 and 1.1
>
> entering 1.1
>
>
>
>
>
> However, placing the onentry in the parent of that atomic substate like this:
>
>
>
> <state id="1">
>
>      <onentry><my:printStates/></onentry>
>
>      <state id="1.1" />
>
> </state>
>
>
>
> gives a result which I hadn't expected:
>
>
>
> entering entry
>
> exiting entry
>
>     my prints 0 states
>
> entering 1
>
> entering 1.1
>
>
>
> Here, the action reports that the engine is in NO STATE AT ALL.
>
> I can see that the action is always executed before the listener reports it's onentry (of which I'm not sure if it's weird or not), but nevertheless it always reports correctly the states it belongs to. Except when the action is executed on a non-atomic state -> then it believes to be in 0 states.
>
>
>
> This looks to me like inconsistent, and thus a bug, or am I overlooking some logic?

Hi Rinke,

This indeed is a bug and the result of how Commons SCXML keeps track of active 
atomic states only, deriving the set of all states from them dynamically.
Clearly in use-cases like yours above this won't be consistent until these 
active atomic states actually have been entered.

I've to think of a proper solution how best to fix this: we might have to track 
both the active and the all states sets in the Status object now.
Which of course will add to its footprint.

If you can create a JIRA issue for it, I'll pick it up from there.

Regards, Ate

>
>
>
> Test classes are available at request.
>
>
>
> best regards, Rinke
>


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