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