You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2014/10/27 23:48:36 UTC
[jira] [Resolved] (SCXML-217) doesn't work correctly
(according to SCXML2 W3C Spec)
[ https://issues.apache.org/jira/browse/SCXML-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved SCXML-217.
-----------------------------
Resolution: Invalid
I'm resolving this issue as invalid, because it actually does work according to the specification.
Please read [3.1.5 'Type' and Transitions|http://www.w3.org/TR/scxml/#N101C6] as it explains this specific use-case in detail.
And for even even more technical detail, read: [SelectingTransitions|http://www.w3.org/TR/scxml/#SelectingTransitions] and the Definition of an exit set in particular.
In you example the transition with event="s3" its source is state "S1" (NOT "S11").
And (by default) for an external transition the SCXML engine must exit all the active descendants of the [LLCA|http://www.w3.org/TR/scxml/#LCCA] of the source and target states.
And, because the parent of "S1" parent is parallel "p" and therefore not a Compound State, in this case the LLCA is the SCXML root node itself, and hence the parallel "p" also needs to be exited.
Anyway, the 'fix' for *this* example is pretty trivial :)
Just add type="internal" to the transition and it'll work as you expected.
But note that this only will work if/when the source of the transition ("S1") itself is a Compound State and all its targets are descendants of it (as in this example).
> <parallel> doesn't work correctly (according to SCXML2 W3C Spec)
> ----------------------------------------------------------------
>
> Key: SCXML-217
> URL: https://issues.apache.org/jira/browse/SCXML-217
> Project: Commons SCXML
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: java version "1.7.0_60"
> Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
> Windows 7
> Reporter: Johannes Neuber
> Priority: Blocker
>
> W3C Specification says: {quote}<parallel>: „... Transitions *within the individual child elements operate normally*. However *whenever a transition is taken with a target outside the <parallel> element, the <parallel> element and all of its child elements are exited* and the corresponding <onexit> …“
> {quote}
> In the current implementation (I tested commons-SCXML2-2.0-SNAPSHOT.jar from the 13th of September) it happens (reproducible) that the <parallel> region is exited also if the target of a <transition> is within the <parallel> region. That’s a real blocker, because it makes the usage <parallel> elements almost impossible in real/big projects:
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
> xmlns:cs="http://commons.apache.org/scxml" initial="p">
> <parallel id="p">
> <transition event="done.state.p" target="end" />
> <state id="S1" initial="S11">
> <state id="S11">
> <transition event="e4" target="S12" />
> </state>
> **<transition event="e3" target="S13" />**
> <state id="S12">
> <transition event="e1" target="S1Final" />
> </state>
> <state id="S13">
> <transition event="e1" target="S1Final" />
> </state>
> <final id="S1Final" />
> </state>
>
> <state id="S2" initial="S21">
> <state id="S21">
> <transition event="e1" target="S22" />
> </state>
> <state id="S22">
> <transition event="e2" target="S2Final"/>
> </state>
> <final id="S2Final" />
> </state>
> </parallel>
> <final id="end"/>
> </scxml>
> {code}
> Output using org.apache.commons.scxml2.test.StandaloneUtils:
> {code}
> 0 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p
> 1 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S1
> 1 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S1/S11
> 1 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S2
> 1 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S2/S21
> {code}
> Ok so far!
> Firing Event *{color:green}e1{color}*
> {code}
> 43257 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p/S2/S21
> 43257 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - transition (event = e1, cond = null, from = /p/S2/S21, to = /p/S2/S22)
> 43257 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S2/S22
> {code}
> Ok so far ...
> Now firing Firing Event *{color:green}e3{color}* (Note */p/S1/S11* and */p/S2/S22* *are* the *active* states now)
> {code}
> 119890 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p/S2/S22
> 119890 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p/S2
> 119890 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p/S1/S11
> 119890 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p/S1
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - exit /p
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - transition (event = e3, cond = null, from = /p/S1, to = /p/S1/S13)
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S1
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S1/S13
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S2
> 119891 [main] INFO org.apache.commons.scxml2.env.SimpleSCXMLListener - enter /p/S2/S21
> {code}
> *{color:red}That's not correct!{color}*
> If the event *e3* is triggered, all <parallel> regions are left! Afterwards state */p/S1/S13* is correctly activated, but unfortunately the other <parallel> region *S2* is changing to it's <initial> state */p/S2/S21*!
> If transition *e3* had a target outside the <parallel> element, this behavior would have been correct. But it doesn't have! It's target is *S13* which is definitely inside the <parallel> element *p*!
> After triggering Event *e3* the state machine must be in the following active states: */p/S1/S13* and *p/S2/S22*. And *only* the <onexit> handler of *S21* has to be executed and the <onentry> handler of state *S13*. Nothing more ...
> If I change the specifications like this, everything works correctly. But that'S not what I/we want:
> {code:xml}
> <transition event="done.state.p" target="end" />
> <state id="S1" initial="S11">
> <state id="S11">
> <transition event="e4" target="S12" />
> <transition event="e3" target="S13" />
> </state>
> <state id="S12">
> <transition event="e1" target="S1Final" />
> </state>
> <state id="S13">
> <transition event="e1" target="S1Final" />
> </state>
> <final id="S1Final" />
> </state>
> {code}
> Do you have an idea for a quick fix?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)