Re: Re: Re: [scxml] bug with script in combination of a chain of transitions
Hi Ate, Ah, I understand the issue now. Thanks for looking at it. best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] bug with script in combination of a chain of transitions
e following when I tested it with the stanadlone tool [1]:
$ ./scxml.sh test.scxml
http://www.w3.org/2005/07/scxml";
xmlns:cs="http://commons.apache.org/scxml"; version="1.0" initial="test1"
datamodel="jexl">
>8 >8
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 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] <a rel="nofollow" href="http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html">http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html</a>
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");
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 .positive,
else it sends .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
--
Re: Re: [scxml] bug with script in combination of a chain of transitions
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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] bug with script in combination of a chain of transitions
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 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] <a rel="nofollow" href="http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html">http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html</a>
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");
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 .positive,
else it sends .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
-
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
Re: Re: [scxml] bug with script in combination of a chain of transitions
pache.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 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] <a rel="nofollow" href="http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html">http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html</a>
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");
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 .positive,
else it sends .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
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] bug with script in combination of a chain of transitions
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:
http://www.w3.org/2005/07/scxml";
version="1.0"
datamodel="jexl"
initial="test1">
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
http://www.w3.org/2005/07/scxml";
xmlns:cs="http://commons.apache.org/scxml"; version="1.0" initial="test1"
datamodel="jexl">
>8 >8
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 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] <a rel="nofollow" href="http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html">http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html</a>
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");
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 .positive,
else it sends .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 scrip
[scxml] bug with script in combination of a chain of transitions
Dear people at scxml,
I found a bug in the scxml commons project.
Consider this scxml file:
agent.storeInMemory("test1.1");
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
.positive, else it sends .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
