[
https://issues.apache.org/jira/browse/SCXML-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved SCXML-206.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.0
I've applied the above mentioned fixes.
Please test and report if this now works for your scenario(s).
Note however that full compliance with the specification is not yet intended:
there are definitely other limitations and mismatches in the current event IO
processing (both internal and external) which will be dealt with later
(Milestone 3 or maybe earlier).
> 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
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> 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.3.4#6332)