[ 
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)

Reply via email to