Johannes Wienke created SCXML-206:
-------------------------------------
Summary: Specification mismatch: event-less transitions are
triggered by named events
Key: SCXML-206
URL: https://issues.apache.org/jira/browse/SCXML-206
Project: Commons SCXML
Issue Type: Bug
Affects Versions: 2.0
Reporter: Johannes Wienke
The SCXML 2 specification indicates the following in section 3.13
{quote}
A transition is enabled by NULL in atomic state S if a) T lacks an 'event'
attribute b) T's source state is S or an ancestor of S c) T lacks an 'cond'
attribute or its 'cond' attribute evaluates to "true". (Note that such a
transition can never be enabled by any named event.)
{quote}
The last aspect that event-less conditions can never be triggered by a named
event is currently violated by the trunk implementation.
Imagine the following example document:
{code:xml}
<scxml xmlns="http://www.w3.org/2005/07/scxml"
xmlns:rsb="http://opensource.cit-ec.de/rsb"
version="1.0" initial="Start" name="CustomActionSequential">
<state id="Start">
<onentry>
<log expr="'Starting onentry of state Start'"></log>
<send event="'test'" delay="'100ms'"></send>
<rsb:generic rsb:class="rsb.scxml.LongRunningAction"
name="first"></rsb:generic>
<log expr="'Finished onentry of state Start'"></log>
</onentry>
<onexit>
<log expr="'onexit of state Start'"></log>
</onexit>
<transition target="End">
</transition>
</state>
<final id="End">
<onentry>
<log expr="'onentry of state End'"></log>
</onentry>
</final>
</scxml>
{code}
The rsb:generic action is simply a custom action that wastes some processing
time by sleeping 1 second.
The logging output that you get when executing this is the following:
{noformat}
Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
INFO: null: Starting onentry of state Start
Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
INFO: null: onexit of state Start
Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
INFO: null: onentry of state End
Aug 29, 2014 11:04:27 AM org.apache.commons.scxml2.model.Log execute
INFO: null: Finished onentry of state Start
{noformat}
As you can see, the named event raised by the send action has triggered the
transition since the outputs are not in the expected sequential order. This
should not happen according to the specification.
On the other hand, if you do not send an event at all, the state machine gets
stuck. This confirms that the transition was actually really triggered by the
sent event. Moreover, it also sounds like a specification mismatch to me. The
respective quote from the specification is:
{quote}
After checking the state configuration, the Processor must select the optimal
transition set enabled by NULL in the current configuration. If the set is not
empty, it must execute it as a microstep.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)