Re: Re: [scxml] bug with script in combination of a chain of transitions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scxml] bug with script in combination of a chain of transitions

rinke
Hi Woonsan, hi others,

At first, sorry for the late reply. I posted the issue in april, but didn't get a response in the first two weeks. Then I forgot about it (busy with other issues), and then just saw your reply, about a week ago.

Anyway, I've been thinking hard about the issue, and I think I now understand what is going on here.

Then again, sorry that my example wasn't so clear, at first. The problem is we're having very complicated scxml schemes working with several custom classes, and I tried to bring the example back to the basics, but probably just missed the key thing.

It basically comes to this, I discovered. Consider this scxml:

<state id="bla">
       <transition event="screening" target="cxr" />
</state>

<state id="cxr">
        <onentry>
                 <ntd:test id="CXR" />
        </onentry>
        <transition event="CXR.negative" target="untreated" />
        <transition event="CXR.positive" target="somethingelse"/>
</state>
<state id="untreated" />

The custom ntd:test tag fires a CXR.negative event.

Now the SCXMLListener reports this for the onentry's and onexit's

...
0.000: Human#0 ONEXIT bla
0.000: Human#0 ONEXIT cxr
0.000: Human#0 ONENTRY untreated
0.000: Human#0 ONENTRY cxr

Note that the problem is that the cxr state's onexit is reported first, and only at the end of the chain the onentry for cxr is reported. The order should have been this:
onexit bla
onentry cxr
onexit cxr
onentry untreated

This doesn't happen with logs, it only happens with my own custom action.

The custom action does some tests, and on basis of the state the engine is in, and has been in (and some other stuff) the outcome is positive or negative.
It then sends back a positive or a negative event, via this code:


            TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent, TriggerEvent.SIGNAL_EVENT, payload) };
            scxmlExecutorInstance.triggerEvents(evts);

where stateMachineEvent is either "<id>.positive" or "<id>.negative".


So what happens is this:
1) state machine exits "bla" -> onexit bla is reported by listener
2) state machine enters "cxr", and goes straight to onentry
3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with "CXR.negative".
4) Still as part of the custom action, the event is caught in the transition tag, and state machine directed to "untreated"
5) the "cxr" state is exited -> onexit cxr reported by listener
6) "untreated" state entered -> onentry untreated reported by listener
7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is reached, only now the custom Actions's execute method is returned.
8) only after the execute method of the custom action returned, the onentry block of "cxr" is finished, and only after that the "onentry cxr" is reported by the listener.


So, conclusion:

A) does this scenario make sense?
B) would you consider this as a bug? The behavior is at least tricky...


Thanks, Rinke




________________________________________________________________________________________

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 <[hidden email]> wrote:

 Subject: [scxml] bug with script in combination of a chain of transitions
 To: "[hidden email]" <[hidden email]>
 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: [hidden email]
 For additional commands, e-mail: [hidden email]
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [scxml] bug with script in combination of a chain of transitions

Ate Douma
Hi Rinke,

I will try to take a look at your issue later (end of) this week.
It would be helpful if you can report against which version you are experiencing
this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0?

Thanks, Ate


On 2015-06-15 22:37, R.C. Hoekstra wrote:

> Hi Woonsan, hi others,
>
> At first, sorry for the late reply. I posted the issue in april, but didn't get a response in the first two weeks. Then I forgot about it (busy with other issues), and then just saw your reply, about a week ago.
>
> Anyway, I've been thinking hard about the issue, and I think I now understand what is going on here.
>
> Then again, sorry that my example wasn't so clear, at first. The problem is we're having very complicated scxml schemes working with several custom classes, and I tried to bring the example back to the basics, but probably just missed the key thing.
>
> It basically comes to this, I discovered. Consider this scxml:
>
> <state id="bla">
>         <transition event="screening" target="cxr" />
> </state>
>
> <state id="cxr">
>          <onentry>
>                   <ntd:test id="CXR" />
>          </onentry>
>          <transition event="CXR.negative" target="untreated" />
>          <transition event="CXR.positive" target="somethingelse"/>
> </state>
> <state id="untreated" />
>
> The custom ntd:test tag fires a CXR.negative event.
>
> Now the SCXMLListener reports this for the onentry's and onexit's
>
> ...
> 0.000: Human#0 ONEXIT bla
> 0.000: Human#0 ONEXIT cxr
> 0.000: Human#0 ONENTRY untreated
> 0.000: Human#0 ONENTRY cxr
>
> Note that the problem is that the cxr state's onexit is reported first, and only at the end of the chain the onentry for cxr is reported. The order should have been this:
> onexit bla
> onentry cxr
> onexit cxr
> onentry untreated
>
> This doesn't happen with logs, it only happens with my own custom action.
>
> The custom action does some tests, and on basis of the state the engine is in, and has been in (and some other stuff) the outcome is positive or negative.
> It then sends back a positive or a negative event, via this code:
>
>
>              TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent, TriggerEvent.SIGNAL_EVENT, payload) };
>              scxmlExecutorInstance.triggerEvents(evts);
>
> where stateMachineEvent is either "<id>.positive" or "<id>.negative".
>
>
> So what happens is this:
> 1) state machine exits "bla" -> onexit bla is reported by listener
> 2) state machine enters "cxr", and goes straight to onentry
> 3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with "CXR.negative".
> 4) Still as part of the custom action, the event is caught in the transition tag, and state machine directed to "untreated"
> 5) the "cxr" state is exited -> onexit cxr reported by listener
> 6) "untreated" state entered -> onentry untreated reported by listener
> 7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is reached, only now the custom Actions's execute method is returned.
> 8) only after the execute method of the custom action returned, the onentry block of "cxr" is finished, and only after that the "onentry cxr" is reported by the listener.
>
>
> So, conclusion:
>
> A) does this scenario make sense?
> B) would you consider this as a bug? The behavior is at least tricky...
>
>
> Thanks, Rinke
>
>
>
>
> ________________________________________________________________________________________
>
> 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 <[hidden email]> wrote:
>
>   Subject: [scxml] bug with script in combination of a chain of transitions
>   To: "[hidden email]" <[hidden email]>
>   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: [hidden email]
>   For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [scxml] bug with script in combination of a chain of transitions

rinke
In reply to this post by rinke
Hi Ate,

Sorry I forgot to mention, it's 2.0-SNAPSHOT.

Thanks for looking at it.

best regards, Rinke


> Date Mon, 22 Jun 2015 23:10:21 GMT
> Hi Rinke,
>
> I will try to take a look at your issue later (end of) this week.
> It would be helpful if you can report against which version you are experiencing
> this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0?
>
> Thanks, Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [scxml] bug with script in combination of a chain of transitions

Ate Douma
In reply to this post by rinke
Hi Rinke,

I just had time to look at your example, and quickly discovered where the
problem is.

Further comments inline below.

Regards, Ate

On 2015-06-15 22:37, R.C. Hoekstra wrote:

> Hi Woonsan, hi others,
>
> At first, sorry for the late reply. I posted the issue in april, but didn't get a response in the first two weeks. Then I forgot about it (busy with other issues), and then just saw your reply, about a week ago.
>
> Anyway, I've been thinking hard about the issue, and I think I now understand what is going on here.
>
> Then again, sorry that my example wasn't so clear, at first. The problem is we're having very complicated scxml schemes working with several custom classes, and I tried to bring the example back to the basics, but probably just missed the key thing.
>
> It basically comes to this, I discovered. Consider this scxml:
>
> <state id="bla">
>         <transition event="screening" target="cxr" />
> </state>
>
> <state id="cxr">
>          <onentry>
>                   <ntd:test id="CXR" />
>          </onentry>
>          <transition event="CXR.negative" target="untreated" />
>          <transition event="CXR.positive" target="somethingelse"/>
> </state>
> <state id="untreated" />
>
> The custom ntd:test tag fires a CXR.negative event.
>
> Now the SCXMLListener reports this for the onentry's and onexit's
>
> ...
> 0.000: Human#0 ONEXIT bla
> 0.000: Human#0 ONEXIT cxr
> 0.000: Human#0 ONENTRY untreated
> 0.000: Human#0 ONENTRY cxr
>
> Note that the problem is that the cxr state's onexit is reported first, and only at the end of the chain the onentry for cxr is reported. The order should have been this:
> onexit bla
> onentry cxr
> onexit cxr
> onentry untreated
>
> This doesn't happen with logs, it only happens with my own custom action.
>
> The custom action does some tests, and on basis of the state the engine is in, and has been in (and some other stuff) the outcome is positive or negative.
> It then sends back a positive or a negative event, via this code:
>
>
>              TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent, TriggerEvent.SIGNAL_EVENT, payload) };

>              scxmlExecutorInstance.triggerEvents(evts);

Here is the culprit: you cannot and may not invoke triggerEvents (reentrant)
from the thread executing the statemachine itself.
SCXML, by specification, is strictly sequential in processing (to ensure
deterministic behavior).
What you should do instead is adding your event to the internal event queue of
the statemachine from within your custom action like:

     @Override
     public void execute(ActionExecutionContext exctx) throws ModelException,
SCXMLExpressionException {
         ...
         TriggerEvent evt = new TriggerEvent(stateMachineEvent,
TriggerEvent.SIGNAL_EVENT, payload);
         exctx.getInternalIOProcessor().addEvent(evt);
     }

This will queue your event to be processed during (at the end of) the current
external event processing, before control is returned back to the statemachine
invoker.

Alternatively, you also can add the event to the external IO event queue via
scxmlExecutorInstance.addEvent(evt).
That will queue your event to be processed after the current (and possible other
pending) external event processing.

Or you can even use the ActionExecutionContext.getEventDispatcher() and dispatch
your event indirectly. In that case you might want to take a look at the Send
class implementation for example.

HTH, Ate


>
> where stateMachineEvent is either "<id>.positive" or "<id>.negative".
>
>
> So what happens is this:
> 1) state machine exits "bla" -> onexit bla is reported by listener
> 2) state machine enters "cxr", and goes straight to onentry
> 3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with "CXR.negative".
> 4) Still as part of the custom action, the event is caught in the transition tag, and state machine directed to "untreated"
> 5) the "cxr" state is exited -> onexit cxr reported by listener
> 6) "untreated" state entered -> onentry untreated reported by listener
> 7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is reached, only now the custom Actions's execute method is returned.
> 8) only after the execute method of the custom action returned, the onentry block of "cxr" is finished, and only after that the "onentry cxr" is reported by the listener.
>
>
> So, conclusion:
>
> A) does this scenario make sense?
> B) would you consider this as a bug? The behavior is at least tricky...
>
>
> Thanks, Rinke
>
>
>
>
> ________________________________________________________________________________________
>
> 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 <[hidden email]> wrote:
>
>   Subject: [scxml] bug with script in combination of a chain of transitions
>   To: "[hidden email]" <[hidden email]>
>   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: [hidden email]
>   For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]