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-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to