commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] featurerequest for new listener SCXMLPostExecutionListener
Date Sun, 20 Jul 2008 13:37:00 GMT
On Fri, Jul 18, 2008 at 6:26 AM, Daniel Schwager
<> wrote:
> Hi Rahul,
> I would like to trigger automat FSM2, if an event1 will fired on the
> FSM1.
> This could be done easily be done using a normal SCXMLListener,
> if a state changed in FSM1.
> But the SCXMLListener will not be called from SCXML, if
> nothing change inside of FSM1 (means, event1 will not map
> to any rule defined in the XML-file).
> So, I have no change to trigger FSM2 via Listener/Action/Invoke
> in this szenario (or did I miss something ?)

In v0.8, using <invoke> triggers all events from the parent state
machine on the child state machine (so FSM1 would be the parent
<invoke>'ing FSM2). However, note that this behavior is currently
under discussion at the Working Group level and is subject to change.
As the Commons SCXML home page notes (in the "Releases" section),
<invoke> is not completely fleshed out yet and the behavior may change
in subsequent releases.

> A Solution could be to implement a new Listener interface
>    Public interface SCXMLPostExecutionListener extends SCXMLListener {
>        // value true, if at least one fsm.trigger() called
>      Void onTrigger(Boolean value)
>        // value true, if fsm.go() called
>        Void onGo(Boolean value)
>        // value true, if at least one onExit/Entry/Transistion occurred
>        Void onExit/Entry/Transition(Boolean value)
>    }
> which, if a SCXMLPostExecutionListener has registered, will be called
> AFTER (post execution) the execution of FSM has finised.

The reason why we set up listeners for exit / transition / entry is
that these are by-products of processing events. The user isn't
actively making each of those individual things to happen. The
suggestions above (such as onTrigger(), onGo() etc.) may be handled by
a "manager" component that is user-provided (we have always advocated
having components that manage the external event queues and overall
lifecycle -- such as go(), trigger(), reset() etc. -- it may be
possible for such a component to turn around and do the "post
execution" bits you are talking about above.)

> Another (but not recommended) solution is to integrate a parallel
> watchdog-state in the FSM1 which will change every time fired by any
> event.
> I do not like this solution (but it works ;-), because I want not
> solve a technical problem (missing of something like
> SCXMLPostExecutionListener)
> by changing the functional automat-description like this

Yes, I see why you don't like it. Incidently, there is no reason to
have the "watchdog_global" state be composite (it doesn't need to have
an <initial> and a <state>, it just needs the one self transition that
the "watchdog" state has).


>  <parallel>
>    <state id="functional_business_logic">
>        ...
>    <state>
>    <state id="watchdog_global">
>        <initial>
>                <transition target="watchdog" />
>        </initial>
>        <state id="watchdog">
>                <transition event="*" target="watchdog" />
>        </state>
>    </state>
>  </parallel>
> Or is there another way to track down my requirement described above ?
> Regards
> Danny
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message