[jira] Reopened: (SCXML-52) Error on resolving conflicting transitions for compound states

["Ingmar Kliche (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SCXML-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingmar Kliche reopened SCXML-52:
--------------------------------


Unfortunately this fix introduced another bug. Now transitions in different regions of a parallel state machine are also discarded. Here is an example:

<scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml" initialstate="main" id="test">
	
<state id = "main">
	<parallel id ="para">
		<state id="s1">
			<initial>
				<transition target="s11"/>
			</initial>
			<state id="s11">
				<transition event="event1" target="s12"/>
			</state>
			<state id="s12">
			</state>
		</state>
		<state id="s2">
			<initial>
				<transition target="s21"/>
			</initial>
			<state id="s21">
				<transition event="event1" target="s22"/>
			</state>
			<state id="s22">
			</state>
		</state>
	</parallel>
</state>
</scxml>

On triggering event "event1" one would expect that two transistions are executed. But only one will be taken.

Here is a test case:

    public void testTieBreaker05() {
        exec = SCXMLTestHelper.getExecutor(tiebreaker05);
        assertNotNull(exec);

        Set currentStates = exec.getCurrentStatus().getStates();
        assertEquals(2, currentStates.size());
        String id = ((State)currentStates.iterator().next()).getId();
        Iterator iter = currentStates.iterator();
        
        while (iter.hasNext()) {
        	id = ((State)iter.next()).getId();
        	assertTrue(id.equals("s11") || id.equals("s21"));
        }
        
        currentStates = SCXMLTestHelper.fireEvent(exec, "event1");
        assertEquals(2, currentStates.size());
        id = ((State)currentStates.iterator().next()).getId();
        iter = currentStates.iterator();
        
        while (iter.hasNext()) {
        	id = ((State)iter.next()).getId();
        	assertTrue(id.equals("s12") || id.equals("s22"));
        }
    }

It shows that the the sub state machine remains in state s21 (i.e. only the transition s11 --> s12 is taken)




> Error on resolving conflicting transitions for compound states
> --------------------------------------------------------------
>
>                 Key: SCXML-52
>                 URL: https://issues.apache.org/jira/browse/SCXML-52
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 0.6
>            Reporter: Ingmar Kliche
>             Fix For: 0.7
>
>
> There seems to be a problem on the resolution of conflicting transitions for compound states. See the following scxml document:
> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initialstate="s1">
>     <datamodel>
>         <data name="x"/>
>     </datamodel>
>     
>     <state id="s1">
>         <initial>
>             <transition target="s11"/>
>         </initial>
>         
>         <transition event="event_1">
>             <assign name="x"  expr="'s1'"/>
>         </transition>
>        
>        <transition event="event_2" target="s1">
>             <assign name="x"  expr="'s1'"/>
>         </transition>
>         
>         <state id="s11">
>             <transition event="event_1">
>                        <assign name="x"  expr="'s11'"/>
>             </transition>
>            <transition event="event_2" target="s11">
>                        <assign name="x"  expr="'s11'"/>
>             </transition>
>         </state>
>     </state>
>     
>     <state id="s2" final="true" />
> </scxml>
> The state machine enters a compound state s1 which contains another state s11 as its intitial state. Both states have transitions on event_1 and event_2. Note that event_1 has no target, whereas event_2 has a target towards the same state.
> For event_2 everything works as expected, i.e. only the transition on state s11 is executed and therefor s11 is reentered (I have a listener in my environment and can monitor this). 
> The error occurs at event_1. On event_1 both transitions of s1 _and_ s11 are executed - but only once. After this, the state machine gets stuck (in particular the currentStates-List is empty). Any subsequent event will not cause any further action.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.