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

Reply via email to