On Mon, Sep 20, 2010 at 5:25 AM, Hallvard Trætteberg <h...@idi.ntnu.no> wrote: > Hi, > > I'm trying to implement a state such that whenever some event (in a > predetermined set) occurs a corresponding actions should be performed, e.g. > whenever event eA occurs, action aA should be performed, whenever event eB > occurs, action aB should be performed etc. I've implemented this using one > targetless transition for each event/action pair, so that the appropriate > action is performed without leaving the state. Now I've discovered that only > the first transition (in document order) is enabled, if several events are > triggered at the same time. I understand that if there are several > transitions out of a state, only one can be enabled. However, none of my > transitions have a target so I thought they could all be enabled at the same > time. What's the reason for not allowing this? > <snip/>
You're correct that in this case both (or more than two) transitions could be selected. The selection process in v0.9 picks the first transition in document order (from each orthogonal region, if there are such regions) without inspecting the transition targets, and that could be changed to pick more if there are no conflicts. However, the correct solution for Commons SCXML is to port the SCXMLSemantics impl in use to match more closely the current algorithm specified in an appendix of the latest SCXML WD which always ensures that only one event is processed at a time (even internal events are queued). This change is slated for v1.0, and needs a JIRA ticket opened against it so it can be tracked -- you can open the ticket if you want, or I'll open it when I get a chance. Unless a patch becomes available, I don't expect to be able to update the impl for atleast another month. One interim solution may be to design a slightly smarter custom action for a wildcarded transition that initiates appropriate processing based on the event(s) being processed. -Rahul > Hallvard > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
