You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Nestor Urquiza <ne...@yahoo.com> on 2006/07/09 15:42:02 UTC
[scxml] TriggerEvent.ERROR_EVENT type behavior
Hello guys,
I guess because of my own mistake at some point I
used:
evts[0] = new TriggerEvent("app.error",
TriggerEvent.ERROR_EVENT, null);
to manage an error assumming that being the type =
"ERROR" and having defined in my scxml:
<n:transition event="app.error" target="IDDLE"/>
the engine would go directly to IDDLE state and no
other code would be executed from the scxml file.
Going thru the code I see that this is wrong
assumption since at least the last version of
SCXMLExecutor#triggerEvents() restores the rest of the
events data (restoreEventData(oldData);) and so the
scxml continues executing the uneeded code.
My question is ... is this a feature could/should be
implemented? This is, when firing an error transition
just ignore the rest of the actions to be executed and
just execute the error event specified by
TriggerEvent() constructor. If this is not an expected
behavior from the SCXML specification I guess I can
have the same behavior if I am able to call
SCXMLExecutor#setEventData() to just clear the pending
events, however this method is private.
Thanks as always for any help,
Nestor
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] TriggerEvent.ERROR_EVENT type behavior
Posted by Nestor Urquiza <ne...@yahoo.com>.
Hello guys,
I just received some explanation from the scxml w3c
forum and what I was trying to do here does not follow
Harel's Sematics.
So we have to stick on flow control statements (if,
else, elseif) and so decide from there what part of
the code gets executed and what part does not get
executed.
In my particular usecase I have a Bridge that gets
calls from a Dispatcher class (which accepts GET/POST
HTTP calls). I automatically call the init() method of
the specific Bridge and if an exception occurs I just
pass the control to the SCXML Engine throwing
"app.error" event. Otherwise I forward the event
corresponding to the service to the SCXML Engine which
then go to an action state.
>From that acton state some preconditions are evauated
in the oninit handler and some of them can fire
exceptions, however now it is different ... I cannot
pass the control to the SCXML Engine hoping it will
take care interrupting the flow. What I have to do is
check return codes to decide if the onentry must
continue using "if else" statements and later just
test for those conditions in transaitions that lead
the state machine to final targets.
In those final targets or states the same process can
be repeated.
An important conclusion for my usecase is that within
action states we never should handle events using
transitions. They are mean to be used only from final
states.
I call those states final just to differentiate them
from the action states. I guess a better term can be
used for them but at this time I cannot come with a
better clasification.
Hope this help to anyone using SCXML to modelate
Satate Oriented Business processes.
Thanks!,
Nestor
--- Nestor Urquiza <ne...@yahoo.com> wrote:
> Sorry guys for the long thread but I continue making
> tests and posting the information I get from them.
> Now
> I present an example in which a given error happens
> in
> the onentry event of the second (after initial)
> state.
> The error launch an event "app.error" that I handle
> in
> the new state and in the initial state just to
> demonstrate that the FSM executes the transition
> from
> the initial state when it is in fact entering the
> second state. Is this behavior correct? I would
> expect
> a different behavior here (going to aIDDLE2HD_ERROR
> instead of going to IDDLE_ERROR)
> test scxml file
> -----------------
> <n:scxml version="1.0" initialstate="IDDLE"
> xmlns:n="http://www.w3.org/2005/07/scxml"
>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.w3.org/2005/07/scxml
>
http://apis.buongiorno.us/white_labels/xml/scxml.xsd">
> <!-- first state uppon first inquire -->
> <n:state id="IDDLE">
> <n:transition event="HandsetDetectionReq"
> target="aIDDLE2HD"/>
> <n:transition event="app.error"
> target="IDDLE_ERROR"/>
> </n:state>
> <state id="aIDDLE2HD">
> <onentry>
> <var name="dummy"
> expr="HandsetDetectionReq.processError(12)"/>
> </onentry>
> <transition event="app.error"
> target="aIDDLE2HD_ERROR"/>
> </state>
> <state id="IDDLE_ERROR">
> </state>
> <state id="aIDDLE2HD_ERROR">
> </state>
> </n:scxml>
>
> the logs:
> --------
> Jul 11, 2006 6:06:10 AM
> org.apache.commons.scxml.SCXMLExecutor logState
> INFO: Current States: [IDDLE]
> Jul 11, 2006 6:06:42 AM
> org.apache.commons.scxml.SCXMLExecutor logState
> INFO: Current States: [IDDLE_ERROR]
> Jul 11, 2006 6:06:45 AM
> org.apache.commons.scxml.SCXMLExecutor logState
> INFO: Current States: [aIDDLE2HD]
>
> Thanks for any help,
> Nestor
>
> --- Nestor Urquiza <ne...@yahoo.com> wrote:
>
> > Going further thru the code and looking to some
> tips
> > from Rahul [1] I still am wondering if the only
> > alternative must be to author custom actions
> > extending
> > the Commons SCXML Action abstract base class.
> >
> > In my specific case I cannot do so since I am
> > relying
> > in a lot of helper method I access from objects
> that
> > I
> > have in the Root Context and for me it is
> impossible
> > to change all those objects.
> >
> > Consider for example:
> > <n:var name="contentSupported"
> > expr="userProfile.isContentSupported( askedContent
> > )"/>
> >
> > userProfile is an instance of UserProfile class
> > which
> > cannot implement the Action abstract class. Still
> I
> > need any error in UserProfile#isContentSupported()
> > to
> > be able to call something like processError() that
> > in
> > turn can just suspend the execution of the state
> > machine by means of calling exactly as suggested
> in
> > [1] :
> > <transition event="err.foo" target="errorstate" />
> >
> > I followed the code and it is not clear how I can
> > accomplish this ... Maybe instead of
> > SCXMLExecutor#triggerEvents we could add something
> > like SCXMLExecutor#triggerException passing the
> > name
> > of the internal event to be passed (err.fo) and
> > ensuring that that event can be the next step to
> be
> > done ignoring any other "standard" or "custom"
> > action?
> >
> > I have been calling my var assignments with the
> > result
> > of my helper methods "custom actions" while I
> > understand they are not really "custom actions"
> from
> > scxml definitions so I rather use thye term once
> > suggested by Rahul I think "specific actions"
> >
> > Any feedback here?, Thanks
> >
> > [1]
> >
>
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114780510526564&w=2
> >
> > --- Nestor Urquiza <ne...@yahoo.com> wrote:
> >
> > > Hello guys,
> > > I guess because of my own mistake at some point
> I
> > > used:
> > > evts[0] = new TriggerEvent("app.error",
> > > TriggerEvent.ERROR_EVENT, null);
> > > to manage an error assumming that being the type
> =
> > > "ERROR" and having defined in my scxml:
> > > <n:transition event="app.error" target="IDDLE"/>
> > > the engine would go directly to IDDLE state and
> no
> > > other code would be executed from the scxml
> file.
> > >
> > > Going thru the code I see that this is wrong
> > > assumption since at least the last version of
> > > SCXMLExecutor#triggerEvents() restores the rest
> of
> > > the
> > > events data (restoreEventData(oldData);) and so
> > the
> > > scxml continues executing the uneeded code.
> > >
> > > My question is ... is this a feature
> could/should
> > be
> > > implemented? This is, when firing an error
> > > transition
> > > just ignore the rest of the actions to be
> executed
> > > and
> > > just execute the error event specified by
> > > TriggerEvent() constructor. If this is not an
> > > expected
> > > behavior from the SCXML specification I guess I
> > can
> > > have the same behavior if I am able to call
> > > SCXMLExecutor#setEventData() to just clear the
> > > pending
> > > events, however this method is private.
> > >
> > > Thanks as always for any help,
> > > Nestor
> > >
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > > protection around
> > > http://mail.yahoo.com
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > commons-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] TriggerEvent.ERROR_EVENT type behavior
Posted by Nestor Urquiza <ne...@yahoo.com>.
Sorry guys for the long thread but I continue making
tests and posting the information I get from them. Now
I present an example in which a given error happens in
the onentry event of the second (after initial) state.
The error launch an event "app.error" that I handle in
the new state and in the initial state just to
demonstrate that the FSM executes the transition from
the initial state when it is in fact entering the
second state. Is this behavior correct? I would expect
a different behavior here (going to aIDDLE2HD_ERROR
instead of going to IDDLE_ERROR)
test scxml file
-----------------
<n:scxml version="1.0" initialstate="IDDLE"
xmlns:n="http://www.w3.org/2005/07/scxml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2005/07/scxml
http://apis.buongiorno.us/white_labels/xml/scxml.xsd">
<!-- first state uppon first inquire -->
<n:state id="IDDLE">
<n:transition event="HandsetDetectionReq"
target="aIDDLE2HD"/>
<n:transition event="app.error"
target="IDDLE_ERROR"/>
</n:state>
<state id="aIDDLE2HD">
<onentry>
<var name="dummy"
expr="HandsetDetectionReq.processError(12)"/>
</onentry>
<transition event="app.error"
target="aIDDLE2HD_ERROR"/>
</state>
<state id="IDDLE_ERROR">
</state>
<state id="aIDDLE2HD_ERROR">
</state>
</n:scxml>
the logs:
--------
Jul 11, 2006 6:06:10 AM
org.apache.commons.scxml.SCXMLExecutor logState
INFO: Current States: [IDDLE]
Jul 11, 2006 6:06:42 AM
org.apache.commons.scxml.SCXMLExecutor logState
INFO: Current States: [IDDLE_ERROR]
Jul 11, 2006 6:06:45 AM
org.apache.commons.scxml.SCXMLExecutor logState
INFO: Current States: [aIDDLE2HD]
Thanks for any help,
Nestor
--- Nestor Urquiza <ne...@yahoo.com> wrote:
> Going further thru the code and looking to some tips
> from Rahul [1] I still am wondering if the only
> alternative must be to author custom actions
> extending
> the Commons SCXML Action abstract base class.
>
> In my specific case I cannot do so since I am
> relying
> in a lot of helper method I access from objects that
> I
> have in the Root Context and for me it is impossible
> to change all those objects.
>
> Consider for example:
> <n:var name="contentSupported"
> expr="userProfile.isContentSupported( askedContent
> )"/>
>
> userProfile is an instance of UserProfile class
> which
> cannot implement the Action abstract class. Still I
> need any error in UserProfile#isContentSupported()
> to
> be able to call something like processError() that
> in
> turn can just suspend the execution of the state
> machine by means of calling exactly as suggested in
> [1] :
> <transition event="err.foo" target="errorstate" />
>
> I followed the code and it is not clear how I can
> accomplish this ... Maybe instead of
> SCXMLExecutor#triggerEvents we could add something
> like SCXMLExecutor#triggerException passing the
> name
> of the internal event to be passed (err.fo) and
> ensuring that that event can be the next step to be
> done ignoring any other "standard" or "custom"
> action?
>
> I have been calling my var assignments with the
> result
> of my helper methods "custom actions" while I
> understand they are not really "custom actions" from
> scxml definitions so I rather use thye term once
> suggested by Rahul I think "specific actions"
>
> Any feedback here?, Thanks
>
> [1]
>
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114780510526564&w=2
>
> --- Nestor Urquiza <ne...@yahoo.com> wrote:
>
> > Hello guys,
> > I guess because of my own mistake at some point I
> > used:
> > evts[0] = new TriggerEvent("app.error",
> > TriggerEvent.ERROR_EVENT, null);
> > to manage an error assumming that being the type =
> > "ERROR" and having defined in my scxml:
> > <n:transition event="app.error" target="IDDLE"/>
> > the engine would go directly to IDDLE state and no
> > other code would be executed from the scxml file.
> >
> > Going thru the code I see that this is wrong
> > assumption since at least the last version of
> > SCXMLExecutor#triggerEvents() restores the rest of
> > the
> > events data (restoreEventData(oldData);) and so
> the
> > scxml continues executing the uneeded code.
> >
> > My question is ... is this a feature could/should
> be
> > implemented? This is, when firing an error
> > transition
> > just ignore the rest of the actions to be executed
> > and
> > just execute the error event specified by
> > TriggerEvent() constructor. If this is not an
> > expected
> > behavior from the SCXML specification I guess I
> can
> > have the same behavior if I am able to call
> > SCXMLExecutor#setEventData() to just clear the
> > pending
> > events, however this method is private.
> >
> > Thanks as always for any help,
> > Nestor
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] TriggerEvent.ERROR_EVENT type behavior
Posted by Nestor Urquiza <ne...@yahoo.com>.
Going further thru the code and looking to some tips
from Rahul [1] I still am wondering if the only
alternative must be to author custom actions extending
the Commons SCXML Action abstract base class.
In my specific case I cannot do so since I am relying
in a lot of helper method I access from objects that I
have in the Root Context and for me it is impossible
to change all those objects.
Consider for example:
<n:var name="contentSupported"
expr="userProfile.isContentSupported( askedContent
)"/>
userProfile is an instance of UserProfile class which
cannot implement the Action abstract class. Still I
need any error in UserProfile#isContentSupported() to
be able to call something like processError() that in
turn can just suspend the execution of the state
machine by means of calling exactly as suggested in
[1] :
<transition event="err.foo" target="errorstate" />
I followed the code and it is not clear how I can
accomplish this ... Maybe instead of
SCXMLExecutor#triggerEvents we could add something
like SCXMLExecutor#triggerException passing the name
of the internal event to be passed (err.fo) and
ensuring that that event can be the next step to be
done ignoring any other "standard" or "custom" action?
I have been calling my var assignments with the result
of my helper methods "custom actions" while I
understand they are not really "custom actions" from
scxml definitions so I rather use thye term once
suggested by Rahul I think "specific actions"
Any feedback here?, Thanks
[1]
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114780510526564&w=2
--- Nestor Urquiza <ne...@yahoo.com> wrote:
> Hello guys,
> I guess because of my own mistake at some point I
> used:
> evts[0] = new TriggerEvent("app.error",
> TriggerEvent.ERROR_EVENT, null);
> to manage an error assumming that being the type =
> "ERROR" and having defined in my scxml:
> <n:transition event="app.error" target="IDDLE"/>
> the engine would go directly to IDDLE state and no
> other code would be executed from the scxml file.
>
> Going thru the code I see that this is wrong
> assumption since at least the last version of
> SCXMLExecutor#triggerEvents() restores the rest of
> the
> events data (restoreEventData(oldData);) and so the
> scxml continues executing the uneeded code.
>
> My question is ... is this a feature could/should be
> implemented? This is, when firing an error
> transition
> just ignore the rest of the actions to be executed
> and
> just execute the error event specified by
> TriggerEvent() constructor. If this is not an
> expected
> behavior from the SCXML specification I guess I can
> have the same behavior if I am able to call
> SCXMLExecutor#setEventData() to just clear the
> pending
> events, however this method is private.
>
> Thanks as always for any help,
> Nestor
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org