On Tue, Sep 28, 2010 at 10:29 AM, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Mon, Sep 27, 2010 at 6:40 AM, Lorenz Schumann | Sysvision GmbH > <lorenz.schum...@sysvision.de> wrote: >> Hi Rahul, >> >> i took over a project in development and took the implementation as the >> correct way to do it. >> But after i read your response (thank you very much by the way!) i re-read >> everything in the documentation. >> >> I want to control a phone application with what scxml can offer me. >> But when i look at the stopwatch example i see a huge difference to our >> approach: When controlling a stopwatch the states change on user action >> (mostly). The user interface sends the events to the statemachine. >> But in our phone application the states change depending on what happens >> inside the invoked code. So we trigger the events inside the invoked code. >> I know there is some fraction of the puzzle i am missing and i cannot see >> how to fire the events from outside to control the statemachine. >> > <snip/> > > I think part of it is that you have started with one of the most > flexible and thereby, harder constructs i.e. invoke to work with. If > the code that you are invoking isn't long running, then you are better > off using constructs that allow for easier synchronous usage for > triggering events. > > >> I also couldn't find any helpful examples. Anything that helps is >> appreciated! >> > <snap/> > > There is an example (related to mobile apps) linked from the home > page, see "Who is using it?" section: > > http://commons.apache.org/scxml/ > > Some details here, code is invoked using custom actions (not using invoke): > > http://mymobileweb.morfeo-project.org/mymobileweb/mymw-tech/scxml > <snip/>
Or this instead: http://forge.morfeo-project.org/wiki_en/index.php/SCXML_Getting_Started -Rahul > I pointed to the guide in the previous email, which has more on custom > actions. > > >> Thanks in advance! >> >> Lorenz >> >> P.S.: I decided to create a minimal example of how i use it right now. Maybe >> it helps... >> >> <?xml version="1.0" encoding="UTF-8"?> >> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" >> initial="enter_pin"> >> >> <state id="enter_pin"> >> <invoke targettype="java" src="EnterPin" /> >> <transition event="fail" target="pin_failed" /> >> <transition event="succ" target="pin_succeeded" /> >> </state> >> >> <state id="pin_failed"> >> <invoke targettype="java" src="HandlePinFailed" /> >> <transition event="finish" target="end" /> >> <transition event="retry" target="enter_pin" /> >> </state> >> >> <state id="pin_succeeded"> >> <invoke targettype="java" src="HandlePinSucceeded" /> >> <transition event="finish" target="end" /> >> </state> >> >> <state id="end" final="true" /> >> >> </scxml> >> >> --------------------- >> >> SCXML scxml = >> SCXMLParser.parse(ClassLoader.getSystemResource("sc.xml"), new >> SimpleErrorHandler()); >> SCXMLExecutor executor = new SCXMLExecutor(new JexlEvaluator(), new >> SimpleDispatcher(), new SimpleErrorReporter()); >> executor.setRootContext(new JexlContext(new HashMap())); >> executor.setStateMachine(scxml); >> // ReflectiveInvoker calls "EnterPin", "HandlePinFailed", etc. by reflection >> executor.registerInvokerClass("java", ReflectiveInvoker.class); >> executor.go(); >> >> --------------------- >> >> Now the most likely completely wrong usage: >> > <snip/> > > Likely, yes. See note at bottom of interface Javadocs: > > http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/invoke/Invoker.html > > -Rahul > > > >> public class EnterPin { >> public void handle(SCInstance sc) { >> ... >> if (success) { >> sc.getExecutor().triggerEvent(new TriggerEvent("succ", >> TriggerEvent.SIGNAL_EVENT)); >> } >> else { >> sc.getExecutor().triggerEvent(new TriggerEvent("fail", >> TriggerEvent.SIGNAL_EVENT)); >> } >> } >> } >> >> >>> On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH >>> <lorenz.schum...@sysvision.de> wrote: >>> >>>> >>>> Hi, >>>> >>>> i am using Commons SCXML for the first time and am overall new to the >>>> Statechart paradigm. >>>> But i am working on a software where a statemachine is needed and the >>>> first >>>> choice fell on commons. >>>> So much for the introduction. >>>> >>>> Now what we discovered is that when you navigate from state to state via >>>> triggering events there is a recursion that makes the method-stack higher >>>> and higher and will at some point throw an StackOverflowError. >>>> This is what the important part of a stacktrace looks like: >>>> >>>> at >>>> >>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160) >>>> at MyInvoker.invoke(MyInvoker.java:23) >>>> at >>>> >>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160) >>>> at MyInvoker.invoke(MyInvoker.java:23) >>>> at >>>> >>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142) >>>> at >>>> >>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160) >>>> at MyInvoker.invoke(MyInvoker.java:23) >>>> >>>> Are we using it as it is meant to be? Is there a way that the execution >>>> of >>>> states is not beeing stacked? >>>> >>>> >>> >>> <snip/> >>> >>> The invoke paradigm is broadly about asynchronously initiating and >>> interacting with external processes. From the trace it looks like your >>> invoker may be synchronously triggering an event on the state machine >>> (which may be initiating the invoke again and so on ad infinitum). >>> Instead, invoke should simply initiate external processing >>> asynchronously and then trigger an event back when the processing is >>> done (or when it fails). >>> >>> Some background on usage is here [1]. >>> >>> If what you are trying to do can be modeled as sending events to >>> existing external processes, you can take a look at<send> and the >>> EventDispatcher instead. >>> >>> If what you are trying to do can be modeled as inherently synchronous >>> executable content within the state machine's<onentry>,<onexit> or >>> <transitions>, then you can have a look a custom actions [2] instead. >>> >>> -Rahul >>> >>> [1] http://commons.apache.org/scxml/guide/using-commons-scxml.html >>> [2] http://commons.apache.org/scxml/guide/custom-actions.html >>> >>> >>> >>> >>>> >>>> Help is much appreciated. >>>> >>>> Lorenz >>>> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org