Hi Rinke,

Did you run with commons-scxml2-2.0-SNAPSHOT?
I've tried to run the following similar to yours on latest revision, but the 
result seems different from what you're seeing:

<?xml version="1.0" ?>
<scxml xmlns="http://www.w3.org/2005/07/scxml";
       version="1.0"
       datamodel="jexl"
       initial="test1">

  <state id="test1" initial="test1.1">

    <state id="test1.1">
      <onentry>
        <log expr="'logging in test1.1'" />
      </onentry>
      <transition event="test1.1.positive" target="test1.2"/>
    </state>

    <state id="test1.2">
      <onentry>
        <log expr="'logging in test1.2'" />
      </onentry>
      <transition event="test1.2.positive" target="test1.3"/>
    </state>

    <state id="test1.3">
      <onentry>
        <log expr="'logging in test1.3'" />
      </onentry>
    </state>

  </state>

</scxml>

I removed the custom action tags and replaced the script tag with simple log 
tags.
And I see the following when I tested it with the stanadlone tool [1]:

$ ./scxml.sh test.scxml 
<?xml version="1.0" encoding="UTF-8"?><scxml 
xmlns="http://www.w3.org/2005/07/scxml"; 
xmlns:cs="http://commons.apache.org/scxml"; version="1.0" initial="test1" 
datamodel="jexl">
---- >8 ---- >8 ----
</scxml>

May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onEntry
INFO: enter /test1
May 05, 2015 11:44:51 PM org.apache.commons.scxml2.model.Log execute
INFO: null: logging in test1.1
May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onEntry
INFO: enter /test1/test1.1
test1.1.positive
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onExit
INFO: exit /test1/test1.1
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onTransition
INFO: transition (event = test1.1.positive, cond = null, from = /test1/test1.1, 
to = /test1/test1.2)
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.model.Log execute
INFO: null: logging in test1.2
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onEntry
INFO: enter /test1/test1.2
test1.2.positive
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onExit
INFO: exit /test1/test1.2
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onTransition
INFO: transition (event = test1.2.positive, cond = null, from = /test1/test1.2, 
to = /test1/test1.3)
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.model.Log execute
INFO: null: logging in test1.3
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onEntry
INFO: enter /test1/test1.3

(I typed 'test1.1.positive' and 'test1.2.positive' to trigger those events 
manually.)

So, the execution order is as follows:
1. enter into test1 state
2. execute actions in onentry of test1.1 state
3. enter into test1.1 state and wait
4. 'test1.1.positive' event triggered manually
5. exit from test1.1 state
6. transition from test1.1 to test 1.2 state
7. execute actions in onentry of test1.2 state
8. enter into test1.2 state
9. 'test1.2.positive' event triggered manually
10. exit from test1.2 state
11. transition from test1.2 to test1.3 state
12. execute actions in onentry of test1.3 state
13. enter into test1.3 state

I don't think <script> action would be different from <log> action in execution 
ordering, so I think you're seeing a different result on your end for some 
reason. Maybe you can try to find what the difference comes from?

Regards,

Woonsan

[1] http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html


--------------------------------------------
On Fri, 4/17/15, R.C. Hoekstra <r.c.hoeks...@erasmusmc.nl> wrote:

 Subject: [scxml] bug with script in combination of a chain of transitions
 To: "user@commons.apache.org" <user@commons.apache.org>
 Date: Friday, April 17, 2015, 4:12 AM
 
 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-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org


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

Reply via email to