Return-Path: 
 <commons-user-return-16292-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 96673 invoked from network); 16 May 2006 16:52:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 16 May 2006 16:52:11 -0000
Received: (qmail 12041 invoked by uid 500); 16 May 2006 16:52:05 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 11990 invoked by uid 500); 16 May 2006 16:52:05 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 11979 invoked by uid 99); 16 May 2006 16:52:05 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2006 09:52:05 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [63.80.142.98] (HELO agile.mail.baypackets.com) (63.80.142.98)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2006 09:52:03 -0700
Received: from prasadsony ([208.188.93.169]) by agile.mail.baypackets.com with
 Microsoft SMTPSVC(6.0.3790.211);
	 Tue, 16 May 2006 09:53:21 -0700
Message-ID: <017301c67909$00717560$a95dbcd0@prasadsony>
From: "Fasih" <fasihullah.askiri@baypackets.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
References: <20060516140612.73391.qmail@web50912.mail.yahoo.com>
Subject: Re: [scxml] Handling exceptions thrown by custom actions
Date: Tue, 16 May 2006 11:51:38 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-OriginalArrivalTime: 16 May 2006 16:53:21.0593 (UTC)
 FILETIME=[3D405290:01C67909]
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

That sure is a complex requirement :)
For the question if we can move the SCXML Engine to move to some state, I am 
not very sure (Where are you Rahul?).
Also, you can look at the <history/> I dont really know what it does, maybe 
you should go through it once to see if it can help you someway.

One more thing, the parallel error handler does pretty much what you are 
looking for except that it keeps you in the custom-action-state and not to 
the INITIAL State, I think you might have to write the handlers for each 
event.

Not of much help I guess. :o

+Fasih

----- Original Message ----- 
From: "Nestor Urquiza" <nestoru@yahoo.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Sent: Tuesday, May 16, 2006 9:06 AM
Subject: Re: [scxml] Handling exceptions thrown by custom actions


> First thanks a lot for your reply and as always they
> are full of ideas that are really helpful.
>
> Second for the particular problem I am presenting I
> have now (Thanks to you) some valid approaches however
> still I have to handle errors one by one and let us be
> more specific "exceptions" which for my program means
> that you should always return an error message in your
> "System".
>
> My question then is a solution to handle thru just one
> common way all of those Exceptional situations that
> happen in the following usecase:
>
> 1)An external event comes to the System (HTTP GET or
> POST for example).
> 2)The System calls a Bridge which can returns the
> control to the System given any Exception there before
> it passes the request to the SCXML Engine.
> 3)The Bridge pass the control to the SCXML Engine and
> a transition from the INITIAL STATE (for this
> transaction) to an Action State is performed.
> 4)Within the onentry internal FSM event some custom
> actions are performed as part of let us say setting
> preconditions.
> 5)If any Exception should be thrown from one of those
> custom actions or specific-code (in any case java
> methods) then the FSM should move to INITIAL STATE and
> returns the control to the Bridge (which was the one
> that triggered the FSM external event).
>
> Again, I think this is a very common situation in
> which a transparent for the SCXML Engine solution
> should exist. So I think that an internal call to the
> SCXML Engine to restore the INITIAL state should
> exists independently of what you of course have as
> utils to handle errors from the SCXML Engine using all
> the approaches you already mentioned.
>
> And then I will reformulate my question ;-)
> Is there a way to instruct the SCXML Engine to go to
> the initial state where the FSM was before the last
> external event was triggered?
>
> --- Fasih <fasihullah.askiri@baypackets.com> wrote:
>
>> 1)You need to include a line managing errors in
>> every
>> > single state that can as result of custom actions
>> > throw an exception.
>> > 2)In case of states that can result from two
>> > transitions comming from two different states then
>> you
>> > cannot use a generic call "application.error" and
>> so
>> > your "Bridges" would be doing decisions that
>> ideally
>> > should be done by the SCXML Engine thru an EL.
>>
>> :)
>> We go back to the post that we once had, have all
>> your states as included
>> states to a parent one, have an transition to the
>> error state on an error
>> event. This would however throw you off the current
>> state.
>> Another way
>> <parallel>
>> <state id="worker">
>> <!-- Throws an exception event, but does not process
>> it -->
>> </state>
>> <state id="error-handler">
>> <initial target="idle"/>
>> <state idle/>
>> <state handle-error/>
>> </state>
>> </parallel>
>> This way you will always be in the orig state and
>> your error will be
>> handled.
>>
>> +Fasih
>> ----- Original Message ----- 
>> From: "Nestor Urquiza" <nestoru@yahoo.com>
>> To: "Jakarta Commons Users List"
>> <commons-user@jakarta.apache.org>
>> Sent: Tuesday, May 16, 2006 7:24 AM
>> Subject: Re: [scxml] Handling exceptions thrown by
>> custom actions
>>
>>
>> >
>> >
>> > --- Fasih <fasihullah.askiri@baypackets.com>
>> wrote:
>> >
>> >> Hi
>> >> When you say a custom action, I believe it is
>> your
>> >> custom action.
>> >
>> > Yes I mean I am executing specific-code like
>> assigning
>> > the result of a method to a variable.
>> >
>> > Now, going
>> >
>> >> by the Java programming practices, "dont catch an
>> >> exception if you cant
>> >> handle it and dont throw one when you know no-one
>> >> can catch it",
>> >
>> > Yep that is my dilema I should not cache this
>> > exception which is supposed to be handle as a
>> critical
>> > error and so managed by either SCXML Engine or by
>> some
>> > generic method in my "Bridge"
>> >
>> >>I would
>> >> rather fire an application.error event with the
>> >> exception msg as the payload
>> >> than throw the exception. To me it makes much
>> more
>> >> sense as this is what the
>> >> SCXML can understand, else handle the exception
>> in
>> >> Java.
>> >
>> > I understand then you are talking about using:
>> > <transition event="application.error"
>> target="error"/>
>> > and I assume that your approach is related to call
>> > from the exception catch block
>> > exec.triggerEvents(evts); whre evts contains
>> > "application.error" and I already did it ... and
>> > thanks it is a valid solution ... however I can
>> see
>> > two problems:
>> > 1)You need to include a line managing errors in
>> every
>> > single state that can as result of custom actions
>> > throw an exception.
>> > 2)In case of states that can result from two
>> > transitions comming from two different states then
>> you
>> > cannot use a generic call "application.error" and
>> so
>> > your "Bridges" would be doing decisions that
>> ideally
>> > should be done by the SCXML Engine thru an EL.
>> >
>> > Wouldn't be easier to have a generic registration
>> of
>> > the starting state using
>> > exec.getCurrentStatus().getStates() then whenever
>> an
>> > exception occurs call a method to just return to
>> that
>> > given initial state? Now if this is a valid
>> approach
>> > which are the mothods you will use to
>> accomplishing
>> > something like this?
>> >
>> >
>> >> By the way, looking at the API for execute I
>> believe
>> >> that the concept of
>> >> derived events was added to signal that the event
>> >> has resulted from some
>> >> other event (As in an exception event as a result
>> of
>> >> the orig event) once it
>> >> is an event, handling it would be simple.
>> >
>> > Interesting, could you put an example of this?
>> Thanks
>> > a lot!,
>> > Nestor
>> >>
>> >> My thoughts anyways, there might be better
>> >> alternatives.
>> >>
>> >> +Fasih
>> >> ----- Original Message ----- 
>> >> From: "Nestor Urquiza" <nestoru@yahoo.com>
>> >> To: "Jakarta Commons Users List"
>> >> <commons-user@jakarta.apache.org>
>> >> Sent: Monday, May 15, 2006 9:47 AM
>> >> Subject: [scxml] Handling exceptions thrown by
>> >> custom actions
>> >>
>> >>
>> >> > Hello guys,
>> >> > Could you point me to what you think might be
>> the
>> >> best
>> >> > approach here?
>> >> >
>> >> > I receive a request and pass that request to
>> the
>> >> scxml
>> >> > engine by means of triggering the proper event.
>> >> The
>> >> > event then put the FSM in an action state where
>> >> some
>> >> > internal methods (custom actions) are called.
>> >> >
>> >> > How could I just suspend the whole execution of
>> >> the
>> >> > trigger and go back to the state the
>> application
>> >> was
>> >> > before receiving the external event? Right now
>> if
>> >> an
>> >> > exception is thrown from a custom action then a
>> >> new
>> >> > SCXMLExpressionException(e) is thrown as well
>> so
>> >> the
>> >> > FSM stops and therefore the FSM stops at the
>> >> action
>> >> > state while of course I want it to go back to
>> the
>> >> > original state.
>> >> >
>> >> > Thanks a lot,
>> >> > Nestor Urquiza
>> >> >
>> >> >
>> __________________________________________________
>> >> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>>
>>
>>
>>
> ---------------------------------------------------------------------
>> 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
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org