commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <>
Subject Re: [SCXML] Event types
Date Thu, 24 May 2007 21:16:36 GMT
Yes, I remember that one a year ago when I started my project ... the Domain/Bridge/Engine
definition convinced me this was the API I was looking for when deciding how to implement
a state oriented business protocol.

In fact the idea of using came from that or another related post as far as I remember.
The proposed solution is then to manage with thrown by the application events (from custom
actions) where to go but as discussed before it won't mean that the rest of the code within
the onentry state won't be executed.

See the following example (borrowed from your post and arbitrarly changed to demonstrate the

<state id="foo">


    <my:action ... />

    <my:action2 ... />

  <transition event="" target="errorstate" />

  <n:transition cond="resultFromAction2 eq true" target="bar"/>
  <!-- other transitions etc. -->


If "action" somehow manages its exceptional situation throwing "" event it wont stop
execution of "action2". Furthermore since chances are more than one transition conditions/events
could be stisfied the FSM could go to two different states at the same time (errorstate and
bar) which of course is not what we want. 

Our target is just to stop action, do not execute action2 and ensure *only* event
is processed as part of the transitions (perhaps because of the fact that it has a higher
priority as suggested before).

Does it make sense?



----- Original Message ----
From: Rahul Akolkar <>
To: Jakarta Commons Users List <>
Sent: Thursday, May 24, 2007 4:10:28 PM
Subject: Re: [SCXML] Event types

On 5/22/07, Nestor Urquiza <> wrote:
> Could you mention in your opinion at least one of the alternatives to modify or create
a new SCXML Semantic implementation to deal with critical errors that are supposed to stop
the normal flow of the application? The Event type could be one that we already saw is not
going to be provided within the library and still seems like the best way to accomplish that

I think this was discussed a couple of times so I tried to look it up
in the archives, though I can only find one reference ATM (see about a
third of the way down in following email):

That along with a couple of related observations ...

 * Stopping a flow is equivalent to redirecting it to a (different)
final state (than what is perceived "normal")
 * Each event name, by itself, specifies a unique "type" of event

... should satisfy many usecases.


> Thanks,
> -Nestor

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

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.

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

View raw message