Thanks Rahul for the answer. Comments below:
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.
Yes, I read the code and noticed that a null target (stay) isn't considered as a special case.
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 at least another month.
I read the specification, but didn't find special mention of the null target case. They do explain why one transition overrules (preempts?) another, when they lead out of a region. However, think the issue of queueing is orthogonal to the issue of selecting more than one target-less transition. You are right that the way I described my case, handling one event at time would solve the issue. But there's no guarantee that an event isn't used several times, so being able to select multiple target-less transitions is best.
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.
My interim solution is to wrap each transition in a state, so they don't compete. It clutters the model, but since it is generated from a DSL, that's not a big issue. Still, I would like SCXML's implementation to be more "reasonable" :-). A final (and hopefully positive and constructive) comment: SCXML's code is tidy and easy to read, so implementing a custom Semantics isn't really that difficult either. What could help, is if some of the methods were split into parts/stages implemented by overridable (protected) methods, so that variations on the official semantics could be implemented in a subclass, without much copying of code. Hallvard --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
