commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hallvard Trætteberg <>
Subject Re: [scxml] Transitions without targets compete for enablement
Date Tue, 21 Sep 2010 08:35:25 GMT

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
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)
so that variations on the official semantics could be implemented in a subclass, without much
copying of code.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message