You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2006/08/28 20:43:40 UTC
Re: [SCXML] How to express 'evnet name/action' of a transition in Commons SCXML?
Corrected prefix in email subject ...
On 8/28/06, Guofeng Zhang <gu...@radvision.com> wrote:
> Hi,
>
> For a transition in a statechart, we can depict the transition as "event
> name/action" in UML diagram, but I do not know how to express it in
> commons SCMXML. I want to call a method in a Java class in the action
> when the event is fired.
>
> I read the user guide and browse the SCMXL specification; they only
> describe how to use actions in a state. I can not figure out how to use
> the action in a transition.
>
> Could anyone kindly give me a sample about it?
>
<snip/>
<transition event="foo.bar" cond="..." target="...">
<my:actions ... /> <!-- one or more standard, or custom actions -->
</transition>
Maybe also see:
http://jakarta.apache.org/commons/scxml/guide/using-commons-scxml.html
for a discussion about what it means to map a generic state machine to
a particular domain of interest.
If you have other questions, please let us know.
-Rahul
>
>
> Thanks.
>
> Guofeng
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Shale + SCXML integration:
Posted by "THOMAS, JAYANT (SBCSI)" <jt...@att.com>.
So we are not parsing the sxcml per request, the current implementation
in the usecase looks like it is parsing the document per session and
storing the scxml executor in the session.
Thanks
Jayant
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, August 30, 2006 2:13 PM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:
On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> If we use an executor per active instance of a dialog (i.e. per
ScxmlContext
> in the sandbox API), then we don't have to worry about anything -- a
JSF
> view can only be accessed by one thread at a time, so we should be OK.
The
> only time we'd have to worry about it is if shared a single executor
for an
> entire user, in session scope.
>
<snap/>
Thats great, thats what the dialog2 patch from earlier today does.
OTOH, the usecases example on the Commons SCXML website follows the
legacy dialog API, so warrants a note to that effect.
All state machine abstractions will have a critical region, wonder how
other "dialog" technologies have solved this.
-Rahul
>
> Craig
>
---------------------------------------------------------------------
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
RE: Shale + SCXML integration:
Posted by "THOMAS, JAYANT (SBCSI)" <jt...@att.com>.
Have Shale framework ever been used in large scale production
environment.
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, August 30, 2006 2:13 PM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:
On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> If we use an executor per active instance of a dialog (i.e. per
ScxmlContext
> in the sandbox API), then we don't have to worry about anything -- a
JSF
> view can only be accessed by one thread at a time, so we should be OK.
The
> only time we'd have to worry about it is if shared a single executor
for an
> entire user, in session scope.
>
<snap/>
Thats great, thats what the dialog2 patch from earlier today does.
OTOH, the usecases example on the Commons SCXML website follows the
legacy dialog API, so warrants a note to that effect.
All state machine abstractions will have a critical region, wonder how
other "dialog" technologies have solved this.
-Rahul
>
> Craig
>
---------------------------------------------------------------------
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
Re: Shale + SCXML integration:
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> If we use an executor per active instance of a dialog (i.e. per ScxmlContext
> in the sandbox API), then we don't have to worry about anything -- a JSF
> view can only be accessed by one thread at a time, so we should be OK. The
> only time we'd have to worry about it is if shared a single executor for an
> entire user, in session scope.
>
<snap/>
Thats great, thats what the dialog2 patch from earlier today does.
OTOH, the usecases example on the Commons SCXML website follows the
legacy dialog API, so warrants a note to that effect.
All state machine abstractions will have a critical region, wonder how
other "dialog" technologies have solved this.
-Rahul
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Shale + SCXML integration:
Posted by Craig McClanahan <cr...@apache.org>.
On 8/30/06, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 8/30/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> > >
> > > Ok, Thanks, so basically for each user/session we will have a single
> > > instance of the SCXMLExecutor
> <snip/>
>
> Yes, additionally, if more than one dialogs is active in the same
> session at the same time, then more than one.
>
>
> >
> > We'll still need to look at synchronization, though ... it's legal for
> there
> > to be multiple requests active on the same session, and the likelihood
> of
> > that increases a lot if you're using AJAX style callbacks.
> >
> <snap/>
>
> Correct, we need to look at it.
If we use an executor per active instance of a dialog (i.e. per ScxmlContext
in the sandbox API), then we don't have to worry about anything -- a JSF
view can only be accessed by one thread at a time, so we should be OK. The
only time we'd have to worry about it is if shared a single executor for an
entire user, in session scope.
-Rahul
Craig
> Thanks
> > > Jayant
> >
> >
> > Craig
> >
> <snip/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: Shale + SCXML integration:
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/30/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> >
> > Ok, Thanks, so basically for each user/session we will have a single
> > instance of the SCXMLExecutor
<snip/>
Yes, additionally, if more than one dialogs is active in the same
session at the same time, then more than one.
>
> We'll still need to look at synchronization, though ... it's legal for there
> to be multiple requests active on the same session, and the likelihood of
> that increases a lot if you're using AJAX style callbacks.
>
<snap/>
Correct, we need to look at it.
-Rahul
> Thanks
> > Jayant
>
>
> Craig
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Shale + SCXML integration:
Posted by Craig McClanahan <cr...@apache.org>.
On 8/30/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
>
> Ok, Thanks, so basically for each user/session we will have a single
> instance of the SCXMLExecutor
We'll still need to look at synchronization, though ... it's legal for there
to be multiple requests active on the same session, and the likelihood of
that increases a lot if you're using AJAX style callbacks.
Thanks
> Jayant
Craig
-----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Wednesday, August 30, 2006 6:45 AM
> To: Jakarta Commons Users List
> Subject: Re: Shale + SCXML integration:
>
>
> On 8/29/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> > Thanks, As you can see SCXMLDialogNavigationHandler is a singleton
> and
> > handleNavigation will be accessed by the many users concurrently. if
> we
> > use servlet context to store the SCXMLExecutor, we have single
> > instance for all the users so the implementation itself will have
> > issues, so which ever framework we use the scxml executor will have
> > issues unless we create a new instance for each request or model the
> > SCXMLExecutor itself as a controller ,
> <snip/>
>
> Not ServletContext (there is no such thing, there is an abstracted out
> ExternalContext) -- but the session map (in that example).
>
>
> > also iam not sure why the
> > SCXMLExecutor is not thread safe ??., we cannot use synchronize blocks
> > in a servlet request since it will block all the request.
> >
> > It will be nice if we can implement the SCXMLExcector as part of the
> > Shale framework itself.
> <snap/>
>
> I agree.
>
> -Rahul
>
>
> > Thanks
> > Jayant
> <snip/>
>
> ---------------------------------------------------------------------
> 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
>
>
RE: Shale + SCXML integration:
Posted by "THOMAS, JAYANT (SBCSI)" <jt...@att.com>.
Ok, Thanks, so basically for each user/session we will have a single
instance of the SCXMLExecutor
Thanks
Jayant
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, August 30, 2006 6:45 AM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:
On 8/29/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> Thanks, As you can see SCXMLDialogNavigationHandler is a singleton
and
> handleNavigation will be accessed by the many users concurrently. if
we
> use servlet context to store the SCXMLExecutor, we have single
> instance for all the users so the implementation itself will have
> issues, so which ever framework we use the scxml executor will have
> issues unless we create a new instance for each request or model the
> SCXMLExecutor itself as a controller ,
<snip/>
Not ServletContext (there is no such thing, there is an abstracted out
ExternalContext) -- but the session map (in that example).
> also iam not sure why the
> SCXMLExecutor is not thread safe ??., we cannot use synchronize blocks
> in a servlet request since it will block all the request.
>
> It will be nice if we can implement the SCXMLExcector as part of the
> Shale framework itself.
<snap/>
I agree.
-Rahul
> Thanks
> Jayant
<snip/>
---------------------------------------------------------------------
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
Re: Shale + SCXML integration:
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/29/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> Thanks, As you can see SCXMLDialogNavigationHandler is a singleton and
> handleNavigation will be accessed by the many users concurrently. if we
> use servlet context to store the SCXMLExecutor, we have single
> instance for all the users so the implementation itself will have
> issues, so which ever framework we use the scxml executor will have
> issues unless we create a new instance for each request or model the
> SCXMLExecutor itself as a controller ,
<snip/>
Not ServletContext (there is no such thing, there is an abstracted out
ExternalContext) -- but the session map (in that example).
> also iam not sure why the
> SCXMLExecutor is not thread safe ??., we cannot use synchronize blocks
> in a servlet request since it will block all the request.
>
> It will be nice if we can implement the SCXMLExcector as part of the
> Shale framework itself.
<snap/>
I agree.
-Rahul
> Thanks
> Jayant
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Shale + SCXML integration:
Posted by "THOMAS, JAYANT (SBCSI)" <jt...@att.com>.
Thanks, As you can see SCXMLDialogNavigationHandler is a singleton and
handleNavigation will be accessed by the many users concurrently. if we
use servlet context to store the SCXMLExecutor, we have single
instance for all the users so the implementation itself will have
issues, so which ever framework we use the scxml executor will have
issues unless we create a new instance for each request or model the
SCXMLExecutor itself as a controller , also iam not sure why the
SCXMLExecutor is not thread safe ??., we cannot use synchronize blocks
in a servlet request since it will block all the request.
It will be nice if we can implement the SCXMLExcector as part of the
Shale framework itself.
Thanks
Jayant
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, August 29, 2006 6:51 AM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:
On 8/29/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> Hi ,
> Based on code for the shale handler implementation, it looks like we
are
> using a single instance of executor ,
<snip/>
Its a single executor instance per user per dialog instance, which is
a lot better ;-)
> On the faq I see the executor is
> not thread safe does this mean this implementation will not work ??
With
> mutiple servlet requests
<snap/>
If you're asking about the specific Shale usecase, I haven't
encountered the need. However, if there is going to be concurrent
access (or a possibility thereof), its best to synchronize on the
executor.
State machine execution is inherently linear, once a event is
triggered, processing must be completed before the next event can be
processed. There can be entire architectures to manage the event
queues (external to the engine), thats out of scope here.
If you're interested in the details of SCXML4Shale, there are ongoing
discussions about the dialog2 sandbox modules on the shale dev list
(dev@shale.apache.org), which might interest you (in which case, hop
on to that list, you can get upto speed here [1]). The dialog2 module
abstracts the state machine implementation out of Shale dialogs,
making it possible to use the Commons SCXML engine for driving Shale
dialogs.
You can follow the dialog2 modules in code here:
http://svn.apache.org/repos/asf/shale/sandbox/
-Rahul
[1] http://www.nabble.com/Shale---Dev-f15682.html
> Thanks
> Jayant
>
---------------------------------------------------------------------
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
Re: Shale + SCXML integration:
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/29/06, THOMAS, JAYANT (SBCSI) <jt...@att.com> wrote:
> Hi ,
> Based on code for the shale handler implementation, it looks like we are
> using a single instance of executor ,
<snip/>
Its a single executor instance per user per dialog instance, which is
a lot better ;-)
> On the faq I see the executor is
> not thread safe does this mean this implementation will not work ?? With
> mutiple servlet requests
<snap/>
If you're asking about the specific Shale usecase, I haven't
encountered the need. However, if there is going to be concurrent
access (or a possibility thereof), its best to synchronize on the
executor.
State machine execution is inherently linear, once a event is
triggered, processing must be completed before the next event can be
processed. There can be entire architectures to manage the event
queues (external to the engine), thats out of scope here.
If you're interested in the details of SCXML4Shale, there are ongoing
discussions about the dialog2 sandbox modules on the shale dev list
(dev@shale.apache.org), which might interest you (in which case, hop
on to that list, you can get upto speed here [1]). The dialog2 module
abstracts the state machine implementation out of Shale dialogs,
making it possible to use the Commons SCXML engine for driving Shale
dialogs.
You can follow the dialog2 modules in code here:
http://svn.apache.org/repos/asf/shale/sandbox/
-Rahul
[1] http://www.nabble.com/Shale---Dev-f15682.html
> Thanks
> Jayant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] How to express 'evnet name/action' of a transition in Commons SCXML?
Posted by Guofeng Zhang <gu...@radvision.com>.
Rahul,
Thanks. It is very helpful.
Does commons SCXML support <script>? I do not find any thing describing
it on the site.
Guofeng
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, August 29, 2006 2:44 AM
To: Jakarta Commons Users List
Subject: Re: [SCXML] How to express 'evnet name/action' of a transition
in Commons SCXML?
Corrected prefix in email subject ...
On 8/28/06, Guofeng Zhang <gu...@radvision.com> wrote:
> Hi,
>
> For a transition in a statechart, we can depict the transition as
"event
> name/action" in UML diagram, but I do not know how to express it in
> commons SCMXML. I want to call a method in a Java class in the action
> when the event is fired.
>
> I read the user guide and browse the SCMXL specification; they only
> describe how to use actions in a state. I can not figure out how to
use
> the action in a transition.
>
> Could anyone kindly give me a sample about it?
>
<snip/>
<transition event="foo.bar" cond="..." target="...">
<my:actions ... /> <!-- one or more standard, or custom actions -->
</transition>
Maybe also see:
http://jakarta.apache.org/commons/scxml/guide/using-commons-scxml.html
for a discussion about what it means to map a generic state machine to
a particular domain of interest.
If you have other questions, please let us know.
-Rahul
>
>
> Thanks.
>
> Guofeng
>
>
---------------------------------------------------------------------
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
Shale + SCXML integration:
Posted by "THOMAS, JAYANT (SBCSI)" <jt...@att.com>.
Hi ,
Based on code for the shale handler implementation, it looks like we are
using a single instance of executor , On the faq I see the executor is
not thread safe does this mean this implementation will not work ?? With
mutiple servlet requests
Thanks
Jayant
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org