commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R.C. Hoekstra" <r.c.hoeks...@erasmusmc.nl>
Subject [scxml] bug with script in combination of a chain of transitions
Date Fri, 17 Apr 2015 08:12:08 GMT
Dear people at scxml, 

I found a bug in the scxml commons project. 

Consider this scxml file: 

    <state id="test1" initial="test1.1">
        <state id="test1.1">
            <onentry>
                <ntd:test id="test1.1" isIn="test1.1" />
                <script> agent.storeInMemory("test1.1"); </script>
            </onentry>
            <transition event="test1.1.positive" target="test1.2"/>
        </state>
        <state id="test1.2">
            <onentry>
                <ntd:test id="test1.2" isIn="test1.1" memory="true" />
            </onentry>
            <transition event="test1.2.positive" target="test1.3"/>
        </state>
        <state id="test1.3"/>
    </state>

There is a custom tag, which simply tests if the state machine is at present in the state
specified in the "isIn" attribute. If it is, it sends an event <id>.positive, else it
sends <id>.negative.
The purpose of this is that we needed a memory: a test that the state machine has at any moment
been in a certain state. That is done via the script tag: via the agent.storeInMemory("test1.1")
call, the test1.1 state is stored in the memory of the agent, and ntd:test tag considers this
memory if the memory=true attribute is specified. As the state test1.1 is stored in memory
while being in state test1.1, the test of test1.2 should return positive, and the test1.2.positive
event should be send.

However, this tests fails. 
The problem is that the script tag appears to be only executed AFTER the chain of all transitions
has been executed and finished, and so the call of the script is too late for the test.  I
had expected the script tag to be executed at entering state test1.1, and not only after having
passed test1.1 and being already in test1.2


The order of entries is also weird: the log shows this order: 

onentry: test1
onentry: test1.2
onentry: test1.1

So you should expect that the onentry for 1.2 happens after 1.1, but it is reversed. 

best regards, Rinke


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


Mime
View raw message