commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <woon_...@yahoo.com.INVALID>
Subject Re: [scxml] bug with script in combination of a chain of transitions
Date Wed, 06 May 2015 04:08:37 GMT
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.hoekstra@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-unsubscribe@commons.apache.org
 For additional commands, e-mail: user-help@commons.apache.org
 

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


Mime
View raw message