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