You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Daniel Schwager <Da...@dtnet.de> on 2008/06/30 23:29:37 UTC
[SCXML] Question save/restore state of FSM
Hi Rahul,
i'm testing/learning/playing around SCXML for about 2 days now. First
of all - great work of this java port (-:
There are two questions i can't find an answer to:
a) Could I realize a transition guarded with a condition checking
a substate of a parallel state ?
<parallel>
<state 1>
<state11/>
<state12/>
<state13/>
</state1>
<state2>
<transition event="a" target="state2"
cond="statemachine is in state state1.state12"/>
<state2/>
<parallel/>
B) i would like to save/restore my FSM (using the SCXML in
EJB3-container with session beans)
Therefore I look around (found also SCXML-19 ..). I realized another
way, but this one
does not work correctly - there's a problem restoring the state ...
maybe you can help me ?
--------------------------------------------------------------------
//Each trigger instances a new Executor, load the old context to it and
fire the event:
Public void myOwnTrigger(Object sm, Trigger evt) {
// Object sm is persistent (loadding before
calling myOwnTrigger() ans saveing after calling ..)
SCXMLExecutor exec = new SCXMLExecutor();
exec.setStateMachine(static-scxml-strng);
exec.setRootContext(sm.getRootContext);
// !! I use a "persistente" root context
exec.setEvaluator(new evaluator);
exec.setErrorReporter(new errReporter);
exec.setEventdispatcher(new
StateMachineEventDispatcher(sm));
// After this, i only added the Listeners immediately, if the FSM never
runs before
if (!sm.isInitialized()) {
// First time - invoke Listener also
exec.addListener(scxml, new
SimpleSCXMLListener());
exec.addListener(scxml, new
StateMachineEntryListener(sm));
sm.setInitialized(true);
exec.go();
// Else, I installed the listeners AFTER exec.go() to prevent to
re-invocations of business method's still done
} else {
// still initialized - involke listener
after FSM is initialized
// (going through all states ..)
exec.go();
exec.addListener(scxml, new
SimpleSCXMLListener());
exec.addListener(scxml, new
StateMachineEntryListener(sm));
}
// Finally, trigger the event
exec.trigger(evt)
return;
--------------------------------------------------------------------
But if i fire _TWO_ "watch.start" to the model
<state id="stopwatch">
<initial>
<transition target="reset" />
</initial>
<state id="reset" final="true">
<onentry/>
<transition event="watch.start" target="running"
/>
</state>
<state id="running">
<onentry/>
</state>
</state>
my solution results in
****************** FIRE EVENT 1
I'm in stopwatch
I'm reset
I'm running
INFO: State(reset) State(stopwatch)
****************** FIRE EVENT 2
I'm running
INFO: State(reset) State(stopwatch)
The correct solution (with the normal way using exec.go() and 2 x
exec.trigger(evt) results in
I'm in stopwatch
I'm reset
I'm running
INFO: State(stopwatch) State(running)
--> My solution enters the "running" state twice, because the state does
not
change from reset->running.... (printed after a new instance of
exec, after exec.go() loaded with the "persistent" context)
Why ? Is there more to save beside of exec.getRootContext() ???
Best regards
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Question save/restore state of FSM
Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/1/08, Daniel Schwager <Da...@dtnet.de> wrote:
<snip/>
> > > Danny from softwaredemo.de (running SCXML inside ;)
> >
>
> > Cool, if you want to be listed in the "Who is using it?" section on
> > the Commons SCXML homepage [1] (see bottom of page), post (on this
> > list) a link and a descriptive sentence about the use to go with it.
>
>
> Sure - please wait until we launch the service (in about 1-2 weeks).
> If you want, I can integrate your SCXML later in our netbeans-6.1
> running on opensolaris
> for the community on softwaredemo.de (-:
>
<snap/>
Even better if you can give something back to the community :-) So
just ping this mailing list when you're ready and want to suggest an
entry in the "whos using it" section.
-Rahul
> Regards
> Danny
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
AW: [SCXML] Question save/restore state of FSM
Posted by Daniel Schwager <Da...@dtnet.de>.
> I will point out that this doesn't persist some interesting bits such
> as (not a complete list):
>
> * Histories (i.e. if you use <history>)
> * Contexts other than the root context (i.e. if you use <cs:var>
etc.)
> * Invokers (i.e. if you use <invoke>)
>
I saw these hints while scanning your code (-:
At the moment, it works - if I use starting history-functionality,
I will recode the persistence as you suggested ..
> > Danny from softwaredemo.de (running SCXML inside ;)
>
> Cool, if you want to be listed in the "Who is using it?" section on
> the Commons SCXML homepage [1] (see bottom of page), post (on this
> list) a link and a descriptive sentence about the use to go with it.
Sure - please wait until we launch the service (in about 1-2 weeks).
If you want, I can integrate your SCXML later in our netbeans-6.1
running on opensolaris
for the community on softwaredemo.de (-:
Regards
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Question save/restore state of FSM
Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/1/08, Daniel Schwager <Da...@dtnet.de> wrote:
> > > B) i would like to save/restore my FSM (using the SCXML in
> > > EJB3-container with session beans)
> > >
>
>
> > In order of preference:
> >
> > 1) Persist the SCXMLExecutor instance below, instead of merely the
> root context.
> >
> > 2) Correctly set the states collection of the current executor status
> > [ exec.getCurrentStatus().getStates() ] along with its root context
> >
>
>
> Hi Rahul,
>
> if i persist the SCXMLExecutor instance, I will also persist all the
> injected codeeobjects like
> Evaluator
> ErrorReporter
> Eventdispatcher
> All Listeners
>
> also. IMHO, it's better to choose your second way.
>
> Now the code works:
>
<snip-code/>
In some scenarios ;-)
I will point out that this doesn't persist some interesting bits such
as (not a complete list):
* Histories (i.e. if you use <history>)
* Contexts other than the root context (i.e. if you use <cs:var> etc.)
* Invokers (i.e. if you use <invoke>)
If you want to avoid persisting the "injected" bits, I'd suggest
"hollowing them out" before persisting, so:
* Use removeListener(...) for addListener(...) before persisting
* Use a lazy initializations (or inject by means available)
Evaluator, ErrorReporter. (or even set them to null before persisting)
This would be a more robust approach IMO.
> Thanks very much
>
> Regards
> Danny from softwaredemo.de (running SCXML inside ;)
>
<snap/>
Cool, if you want to be listed in the "Who is using it?" section on
the Commons SCXML homepage [1] (see bottom of page), post (on this
list) a link and a descriptive sentence about the use to go with it.
-Rahul
[1] http://commons.apache.org/scxml/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
AW: [SCXML] Question save/restore state of FSM
Posted by Daniel Schwager <Da...@dtnet.de>.
> > B) i would like to save/restore my FSM (using the SCXML in
> > EJB3-container with session beans)
> >
> In order of preference:
>
> 1) Persist the SCXMLExecutor instance below, instead of merely the
root context.
>
> 2) Correctly set the states collection of the current executor status
> [ exec.getCurrentStatus().getStates() ] along with its root context
>
Hi Rahul,
if i persist the SCXMLExecutor instance, I will also persist all the
injected codeeobjects like
Evaluator
ErrorReporter
Eventdispatcher
All Listeners
also. IMHO, it's better to choose your second way.
Now the code works:
// init exec
....
if (!sm.isInitialized()) {
// First time - invoke Listener and
reset FSM
exec.addListener(scxml, new
SimpleSCXMLListener());
exec.addListener(scxml, new
StateMachineEntryListener(sm));
sm.setInitialized(true);
exec.go();
} else {
// reload the states
exec.getCurrentStatus().getStates().clear();
exec.getCurrentStatus().getStates().addAll(sm.getStates());
exec.addListener(scxml, new
SimpleSCXMLListener());
exec.addListener(scxml, new
StateMachineEntryListener(sm));
}
exec.triggerEvent(evt);
// Save states
sm.getStates().clear();
sm.getStates().addAll(exec.getCurrentStatus().getStates());
Thanks very much
Regards
Danny from softwaredemo.de (running SCXML inside ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Question save/restore state of FSM
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/30/08, Daniel Schwager <Da...@dtnet.de> wrote:
> Hi Rahul,
>
> i'm testing/learning/playing around SCXML for about 2 days now. First
> of all - great work of this java port (-:
>
> There are two questions i can't find an answer to:
>
> a) Could I realize a transition guarded with a condition checking
> a substate of a parallel state ?
> <parallel>
> <state 1>
> <state11/>
> <state12/>
> <state13/>
> </state1>
> <state2>
> <transition event="a" target="state2"
> cond="statemachine is in state state1.state12"/>
> <state2/>
> <parallel/>
>
<snip/>
Use the In() predicate like so:
... cond="In('state12')" ...
>
> B) i would like to save/restore my FSM (using the SCXML in
> EJB3-container with session beans)
> Therefore I look around (found also SCXML-19 ..). I realized another
> way, but this one
> does not work correctly - there's a problem restoring the state ...
> maybe you can help me ?
>
>
> --------------------------------------------------------------------
>
> //Each trigger instances a new Executor, load the old context to it and
> fire the event:
>
> Public void myOwnTrigger(Object sm, Trigger evt) {
> // Object sm is persistent (loadding before
> calling myOwnTrigger() ans saveing after calling ..)
>
<snap/>
In order of preference:
1) Persist the SCXMLExecutor instance below, instead of merely the root context.
2) Correctly set the states collection of the current executor status
[ exec.getCurrentStatus().getStates() ] along with its root context
-Rahul
> SCXMLExecutor exec = new SCXMLExecutor();
> exec.setStateMachine(static-scxml-strng);
> exec.setRootContext(sm.getRootContext);
> // !! I use a "persistente" root context
> exec.setEvaluator(new evaluator);
> exec.setErrorReporter(new errReporter);
> exec.setEventdispatcher(new
> StateMachineEventDispatcher(sm));
>
> // After this, i only added the Listeners immediately, if the FSM never
> runs before
> if (!sm.isInitialized()) {
> // First time - invoke Listener also
> exec.addListener(scxml, new
> SimpleSCXMLListener());
> exec.addListener(scxml, new
> StateMachineEntryListener(sm));
> sm.setInitialized(true);
> exec.go();
>
> // Else, I installed the listeners AFTER exec.go() to prevent to
> re-invocations of business method's still done
> } else {
> // still initialized - involke listener
> after FSM is initialized
> // (going through all states ..)
> exec.go();
> exec.addListener(scxml, new
> SimpleSCXMLListener());
> exec.addListener(scxml, new
> StateMachineEntryListener(sm));
> }
>
> // Finally, trigger the event
> exec.trigger(evt)
> return;
>
> --------------------------------------------------------------------
>
> But if i fire _TWO_ "watch.start" to the model
> <state id="stopwatch">
> <initial>
> <transition target="reset" />
> </initial>
>
> <state id="reset" final="true">
> <onentry/>
> <transition event="watch.start" target="running"
> />
> </state>
>
> <state id="running">
> <onentry/>
> </state>
> </state>
>
>
> my solution results in
> ****************** FIRE EVENT 1
> I'm in stopwatch
> I'm reset
> I'm running
> INFO: State(reset) State(stopwatch)
> ****************** FIRE EVENT 2
> I'm running
> INFO: State(reset) State(stopwatch)
>
> The correct solution (with the normal way using exec.go() and 2 x
> exec.trigger(evt) results in
> I'm in stopwatch
> I'm reset
> I'm running
> INFO: State(stopwatch) State(running)
>
> --> My solution enters the "running" state twice, because the state does
> not
> change from reset->running.... (printed after a new instance of
> exec, after exec.go() loaded with the "persistent" context)
>
> Why ? Is there more to save beside of exec.getRootContext() ???
>
> Best regards
> Danny
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org