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 2005/12/06 08:01:39 UTC
Re: [SCXML] Help with SCXML Send usage
Hi Mike -
This is an interesting question, but before I attempt to answer --
I've modified the email subject with a [SCXML] prefix, please try to
add the prefix when you start a thread, since some of us have email
filters set up.
On 12/5/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> We are trying to parse/use the content between <send> </send> tags and
> everything we try using the SCXML digester and Send methods retrieves
> null. We have successfully captured the <var> values, but nothing
> within <send> tags. Can you please provide information on how to
> retrieve this content using the code? Our SCXML test document is below:
>
> <?xml version="1.0"?>
> <scxml xmlns="http://www.w3.org/2005/07/SCXML"
> version="1.0"
> initialstate="logoff">
>
> <state id="logoff">
> <onentry>
> <var name="drink" expr="water" />
> <var name="eat" expr="flies" />
> <send target="http://localhost:8080/VXMLInterpreter"
> targettype="v3" xmlns:v3="http://www.w3.org/2005/07/vxml3"
> namelist="drink eat" event="" hints="" sendid="" delay="0">
> <v3:form id="Welcome">
> <v3:block><v3:prompt>Please enter your
> name.</v3:prompt></v3:block>
> </v3:form>
> </send>
> <log expr="'@@@@@@executed send@@@@@@@@'"/>
>
> <cancel sendId="send12345"/>
> </onentry>
>
> <transition event="go_login">
> <target next="login"/>
> </transition>
> </state>
>
> <state id="login">
> <transition event="go_logoff">
> <target next="logoff"/>
> </transition>
> </state>
>
> </scxml>
>
>
> Please help in allowing us to get the SCXML code to work. We've tried
> getExternalNodes() within Send and looked into the Rules for digester
> and do not know how to retrieve the <send>text</send> body elements.
>
<snip/>
Sorry, that digester rule is not in the current SCXMLDigester [1]. Let
me take this up as a TODO for myself, I'll try to get to this during
the upcoming weekend. I'll attempt to use NodeCreateRule [2] to
prepare the external nodes, but since we also need to process the
known bits of the SCXML <send> element, there'll be more than one
digester rule involved.
This will allow the SCXML engine to react to external namespaces, as
long as the EventDispatcher [3] can locate a suitable namespace
handler. I believe SCXML has much promise when it comes to playing in
Compound Document Frameworks.
Having said that, a different approach is equally powerful, and
available immediately. I have written applications which do exactly
what you're alluding to above i.e. thinking of conversations as states
and transitions where each state has a corresponding activity which
might be a dialog of arbitrary complexity (one or more prompts and
replies, client side interaction or even multiple round trips to the
server).
IIRC you've looked at the RDC framework [4], and it provides a SCXML
dialog management strategy for the group container [5]. A very simple,
fictitious use case example is here [6] for which the SCXML controller
is here [7]. Wrapping each activity in a RDC gives us:
a) A separation between the controller and the view
b) The interaction that needs to happen when you're in a particular
state can be fairly involved including any number of client server
round trips
c) You can make decisions about the transition you'd want to follow
based on prior interaction(s)
The separation in (a) is especially useful if you're authoring
multi-channel applications (voice, GUI, small device) since it
encourages reuse across different view layer markup. We have a multi
channel example [8] in the RDC distro which uses Struts wildcard
mappings and I've also demonstrated a proof of concept of how SCXML
can play in Struts Shale.
Please let me know if you have any other questions about SCXML, or how
it can be used to control a VoiceXML based conversation.
-Rahul
[1] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java?view=markup
[2] http://jakarta.apache.org/commons/digester/commons-digester-1.7/docs/api/org/apache/commons/digester/NodeCreateRule.html
[3] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/EventDispatcher.java?view=markup
[4] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
[5] http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials/Aggregation
[6] http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examples/web/scxml-dialog-test.jsp?view=markup
[7] http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examples/web/config/scxml/scxml-test.xml?view=markup
[8] http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examples/web/musicstore-app/README?view=markup
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] SCXMLDigester setNamespaceAware
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/16/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> No, just namespace URIs (I'll confirm Sunday night), but as we
> constructed SOAP-ENV message within send tags, our web service wouldn't
> accept the format of the message. After turning off setNamespaceAware
> (set to false), it worked? We can either send via encoded URI (REST) or
> merely add the SOAP env and pass it on - very cool!
>
<snip/>
>
> Below is example of output to client (transform is determined by which
> plug-in they access, usually a servlet but can be IM Gateway, SMS
> Gateway, etc., just implementing our plug-in Interface)...
>
<snip-example/>
>
> We transform
> vxml response depending on client (rich text, vxml, text, html, etc.).
> It's built to be very flexible, we can even interact with REST WS or any
> encoded URI access to an app via <var> and namelist along with URI as
> target. I'm not sure about performance of the whole thing - may add LRU
> Cache - but it does what I wanted it to and qualifies as an end-to-end
> SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
> :-) Probably first in the world I imagine! :-O Anyone need a bot
> built, in minutes?
>
<snap/>
Super! You've demonstrated what some of us have merely claimed to be
the advantages obtained by using Commons SCXML in web-based
applications:
* Separation of "dialog flow" from "views"
* The multiple channels and devices aspect (catering markup to device
and modality used by end user)
* Event triggered messages sent to external components (servlets,
web-services calls, SOAP over HTTP, what have you)
This is great stuff, Mike :-)
> Given digester is Open, a knowing (or unknowing like myself) individual
> can theoretically customize as they see fit. As such, perhaps just
> leave it alone or implement the solution you mention.
>
<snip/>
I see the theory, makes sense to give the SCXMLDigester class a
Factory flavor. I'll add this to my TODO list for the weekend, will
probably get to it tomorrow.
> As a final note, if you have any input to W3C spec, I suggest removing
> mutual exclusivity of either namelist vars OR send body contents. I
> believe they are supposed to throw fetch.error or something. Commons
> SCXML does not, but as I stated before, I think this is best as it's
> nice to access to some vars in context that may not necessarily be used
> for messages, etc.
>
<snap/>
As far as feedback is concerned, the W3C based on my understanding and
experience (arguably, limited experience), is open to suggestions from
everyone. There are public mailing lists -- to which anyone can
subscribe, just like the lists here at Apache -- and offer feedback. I
would recommend you post any suggestions about the specification
itself on the Voice Browser Working Group's (the SCXML spec is
currently a Working Draft out of the VBWG) public mailing list.
> Cheers,
>
>
> Mike
>
> P.S. - where do you work? And are you in US?
>
<snip/>
I'm in the big apple, where the big blue keeps me busy during the day.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] SCXMLDigester setNamespaceAware
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
No, just namespace URIs (I'll confirm Sunday night), but as we
constructed SOAP-ENV message within send tags, our web service wouldn't
accept the format of the message. After turning off setNamespaceAware
(set to false), it worked? We can either send via encoded URI (REST) or
merely add the SOAP env and pass it on - very cool!
<transition event="double" >
<var name="cb" expr="${Conversation}" />
<send target="http://localhost:8080/goomzee/Calculator.jws"
targettype="appManager" event="talk" namelist="cb" delay="0" hints=""
sendid="2345" >
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:add
xmlns:ns1="http://localhost:8080/goomzee/Calculator.jws"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<i1 xsi:type="xsd:int">${cb.request}</i1>
<i2 xsi:type="xsd:int">${cb.request}</i2>
</ns1:add>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
</send>
<target next="state_login" />
</transition>
Everything's working but I am keeping things under wraps for now. Plus
there are a few automation/stub features that need tweaking and some
code cleanup and documentation TODO. Above is the transition we use
that actually interacts w/ our simple web service. For some reason,
when we had setNamespaceAware(true) the messages wouldn't work. I
suggested setting to false and it worked? We finished at 6am (6:30PM
Friday in india) so I sent my 'helper' away for RESTful weekend ;-).
I'll find out exactly what was wrong Sunday eve (Monday morn IST).
Below is example of output to client (transform is determined by which
plug-in they access, usually a servlet but can be IM Gateway, SMS
Gateway, etc., just implementing our plug-in Interface)...
<transition event="menu">
<var name="cb" expr="${Conversation}" />
<send target="http://localhost:8080/goomzee" targettype="scxml"
event="greet" namelist="cb" delay="0" hints="" sendid="2345">
<menu>
<prompt>
What do you want to do? <enumerate/>
</prompt>
<choice>
1. Chat
</choice>
<choice>
2. Logoff
</choice>
</menu>
</send >
<target next="state_welcome" />
</transition>
Above is an example transition that sends output to user. We transform
vxml response depending on client (rich text, vxml, text, html, etc.).
It's built to be very flexible, we can even interact with REST WS or any
encoded URI access to an app via <var> and namelist along with URI as
target. I'm not sure about performance of the whole thing - may add LRU
Cache - but it does what I wanted it to and qualifies as an end-to-end
SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
:-) Probably first in the world I imagine! :-O Anyone need a bot
built, in minutes?
Given digester is Open, a knowing (or unknowing like myself) individual
can theoretically customize as they see fit. As such, perhaps just
leave it alone or implement the solution you mention.
As a final note, if you have any input to W3C spec, I suggest removing
mutual exclusivity of either namelist vars OR send body contents. I
believe they are supposed to throw fetch.error or something. Commons
SCXML does not, but as I stated before, I think this is best as it's
nice to access to some vars in context that may not necessarily be used
for messages, etc.
Cheers,
Mike
P.S. - where do you work? And are you in US?
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Friday, December 16, 2005 12:55 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] SCXMLDigester setNamespaceAware
On 12/15/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Everything is working except one issue. As we added
> setNamespaceAware(true) in the digester, it adds some "junk" to our
> soap message within the send tags.
<snip/>
"Junk" as in namespace URIs? Is there anything else?
> For our specific purpose, it seems
> unnecessary, but do you think making that setNamespaceAware(true)
> should be configurable? This way, for our use, we have strictly
> defined the xml format to client/app so we don't need namespaces but
> others may. For now, we'll just change that value to false but I
> propose that is configurable value.
>
<snap/>
If we need configurability, IMO, it would be better to open up some of
the SCXMLDigester API so it can also be treated as a Factory class for
suitably configured Digester instances, with the newInstance() method
-- and updateSCXML() for completion -- being public.
That would give users freedom to configure more than just
namespace-awareness. But, freedom has a price (being able to use it
correctly), so lets give this some more thought (which is why I'm asking
about your particular use case).
-Rahul
> Cheers,
>
>
> Mike
>
<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: [SCXML] SCXMLDigester setNamespaceAware
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/15/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Everything is working except one issue. As we added
> setNamespaceAware(true) in the digester, it adds some "junk" to our soap
> message within the send tags.
<snip/>
"Junk" as in namespace URIs? Is there anything else?
> For our specific purpose, it seems
> unnecessary, but do you think making that setNamespaceAware(true) should
> be configurable? This way, for our use, we have strictly defined the
> xml format to client/app so we don't need namespaces but others may.
> For now, we'll just change that value to false but I propose that is
> configurable value.
>
<snap/>
If we need configurability, IMO, it would be better to open up some of
the SCXMLDigester API so it can also be treated as a Factory class for
suitably configured Digester instances, with the newInstance() method
-- and updateSCXML() for completion -- being public.
That would give users freedom to configure more than just
namespace-awareness. But, freedom has a price (being able to use it
correctly), so lets give this some more thought (which is why I'm
asking about your particular use case).
-Rahul
> Cheers,
>
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
Please disregard. Our initial solution leveraged vars (response=foo) to
be sent for processing response, hence the need for context. As we
updated the EventDispatcher.send, we now leverage <send> body contents
for all messaging thus no need. Our workaround was the only reason for
the need, but since <send> works now, everything is peachy! :-)
Thanks,
Mike
-----Original Message-----
From: Mike Sparr - www.goomzee.com [mailto:mike@goomzee.com]
Sent: Wednesday, December 14, 2005 11:15 PM
To: 'Jakarta Commons Users List'
Subject: RE: [SCXML] Concurrent users
Hi Rahul,
I envision we use <send> two ways, one for sending information to client
and other for passing information to application for processing. As
such, we need to send along handle and user input to application so it
can return response to client. It seems that the Listener somehow
"loses" the context upon initial entry, but then when an event is fired
by the user, it "finds" the contexts and has access to vars.
Make sense?
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Two issues reported:
>
> EventDispatcher#send
> - inability to access context
<snip/>
Which is per design. Can you elaborate why the context should be
accessible?
> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)
<snap/>
Yup, fixed in SVN :-)
>
> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we
> would have to instantiate an SCXML obj (stateMachine) for each as well
> as executor?
<snip/>
> You mention "appropriately configured Executor" below. I wonder if
> you suggest each Executor instance also has its own unique state
> machine (SCXML obj) instance too.
<snap/>
Yes, the SCXML object is the in-memory representation of an instance of
the state machine. The evaluation contexts hang off of each State within
the SCXML object, and so the reset method is clearing the contexts for
this instance of the state machine. For each new user/session, a new
instance is called for (SCXML as well as SCXMLExecutor).
> If so, I'm curious what implications this
> would have on memory.
<snip/>
The SCXML Java object model is fairly lightweight. Since your usecase is
in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause for
concern.
-Rahul
> Regards,
>
>
> Mike
>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[SCXML] SCXMLDigester setNamespaceAware
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
Everything is working except one issue. As we added
setNamespaceAware(true) in the digester, it adds some "junk" to our soap
message within the send tags. For our specific purpose, it seems
unnecessary, but do you think making that setNamespaceAware(true) should
be configurable? This way, for our use, we have strictly defined the
xml format to client/app so we don't need namespaces but others may.
For now, we'll just change that value to false but I propose that is
configurable value.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Two issues reported:
>
> EventDispatcher#send
> - inability to access context
<snip/>
Which is per design. Can you elaborate why the context should be
accessible?
> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)
<snap/>
Yup, fixed in SVN :-)
>
> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we
> would have to instantiate an SCXML obj (stateMachine) for each as well
> as executor?
<snip/>
> You mention "appropriately configured Executor" below. I wonder if
> you suggest each Executor instance also has its own unique state
> machine (SCXML obj) instance too.
<snap/>
Yes, the SCXML object is the in-memory representation of an instance of
the state machine. The evaluation contexts hang off of each State within
the SCXML object, and so the reset method is clearing the contexts for
this instance of the state machine. For each new user/session, a new
instance is called for (SCXML as well as SCXMLExecutor).
> If so, I'm curious what implications this
> would have on memory.
<snip/>
The SCXML Java object model is fairly lightweight. Since your usecase is
in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause for
concern.
-Rahul
> Regards,
>
>
> Mike
>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
I envision we use <send> two ways, one for sending information to client
and other for passing information to application for processing. As
such, we need to send along handle and user input to application so it
can return response to client. It seems that the Listener somehow
"loses" the context upon initial entry, but then when an event is fired
by the user, it "finds" the contexts and has access to vars.
Make sense?
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Two issues reported:
>
> EventDispatcher#send
> - inability to access context
<snip/>
Which is per design. Can you elaborate why the context should be
accessible?
> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)
<snap/>
Yup, fixed in SVN :-)
>
> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we
> would have to instantiate an SCXML obj (stateMachine) for each as well
> as executor?
<snip/>
> You mention "appropriately configured Executor" below. I wonder if
> you suggest each Executor instance also has its own unique state
> machine (SCXML obj) instance too.
<snap/>
Yes, the SCXML object is the in-memory representation of an instance of
the state machine. The evaluation contexts hang off of each State within
the SCXML object, and so the reset method is clearing the contexts for
this instance of the state machine. For each new user/session, a new
instance is called for (SCXML as well as SCXMLExecutor).
> If so, I'm curious what implications this
> would have on memory.
<snip/>
The SCXML Java object model is fairly lightweight. Since your usecase is
in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause for
concern.
-Rahul
> Regards,
>
>
> Mike
>
---------------------------------------------------------------------
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: [SCXML] Concurrent users
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Two issues reported:
>
> EventDispatcher#send
> - inability to access context
<snip/>
Which is per design. Can you elaborate why the context should be accessible?
> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)
<snap/>
Yup, fixed in SVN :-)
>
> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we
> would have to instantiate an SCXML obj (stateMachine) for each as well
> as executor?
<snip/>
> You mention "appropriately configured Executor" below. I wonder if you
> suggest each Executor instance also has its own unique state machine
> (SCXML obj) instance too.
<snap/>
Yes, the SCXML object is the in-memory representation of an instance
of the state machine. The evaluation contexts hang off of each State
within the SCXML object, and so the reset method is clearing the
contexts for this instance of the state machine. For each new
user/session, a new instance is called for (SCXML as well as
SCXMLExecutor).
> If so, I'm curious what implications this
> would have on memory.
<snip/>
The SCXML Java object model is fairly lightweight. Since your usecase
is in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause
for concern.
-Rahul
> Regards,
>
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
I suspect the null context value is our implementation but will look
into that tonight. If we cannot figure out, I do appreciate your
offering another set of eyes. My 'helper' had originally stored the
executor per client type and not per client, hence the concurrency
issue... I think we got it sorted:
private SCXMLExecutor getExec(String clientIdentifier){
SCXMLExecutor
exec=(SCXMLExecutor)scxmlExecutorStore.get(clientIdentifier);
if(exec==null){
try {
exec = new SCXMLExecutor(engine,new SimpleDispatcher(),
new SimpleErrorReporter());
exec.setSuperStep(true);
exec.setStateMachine(scxml);
scxmlExecutorStore.put(clientIdentifier,exec);
}catch (ModelException me){
me.printStackTrace();
}
}
return exec;
}
Thanks and I will look at those use cases. I had figured you must've
designed for more than a single threaded use.. After all, what if I want
to control all 10 of my microwaves at once! :-)
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 13, 2005 12:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/12/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> Your code worked (from your personal snapshot) fine - thanks.
<snip/>
OK, thanks for the update :-)
> One issue
> we're now facing is handling concurrent users from multiple clients.
> My goal is to use one scxml doc to manage app flow for all users.
<snap/>
Indeed, there will usually be only one SCXML document for a particular
application task (or flow, or dialog) -- which could be of arbitrary
granularity -- yet the per user (or per session) "instances" of the
state machine must be able to execute independently.
> It looks
> like there is one context and it's shared, so if we trigger an event,
> it will affect any user.
<snip/>
Each user should have a separate Commons SCXML engine (or more
precisely, an instance of the org.apache.commons.scxml.SCXMLExecutor
class) assigned, and the events must be channeled to the appropriate
engine for the same user/session.
> We have created a HashMap (in memory) to store
> key/handle to client for sending response, but are having troubles
> dealing with concurrent users and their state.
>
> For example:
>
> Web request (state 1, event 3)
> IM request (state 2, event 1)
>
> Can the engine handle that or do you know how best to implement? My
> thought was to store state and last event per user, then navigate to
> that somehow for their requests. I assume there must be a better way?
>
<snap/>
We have a couple of published Commons SCXML usecases here:
http://jakarta.apache.org/commons/sandbox/scxml/usecases.html
Both the usecases are examples within a servlet container environment
(so similar to what you're attempting), and the SCXMLExecutor instance
gets created when needed, then cached and retrieved from the user's
session.
To summarize:
* A SCXML document describes the state machine for a task/flow/dialog
in an application.
* The org.apache.commons.scxml.model.SCXML class is the representation
of the document using the Commons SCXML Java object model.
* An appropriately configured SCXMLExecutor instance creates a "live"
state machine (or engine) upon which external events may be fired.
* SCXMLExecutor instances must be created per user/session and cached
throughout the life of the task/flow/dialog.
-Rahul
> Thanks,
>
>
> Mike
>
---------------------------------------------------------------------
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: [SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
Two issues reported:
EventDispatcher#send
- inability to access context
- inability to access externalNodes (solved in prior thread - adding
externalNodes to method signature)
SCXMLExecutor#reset
- reset method resets ALL context(s)
? should have reset for only that user's context, but to do that, we
would have to instantiate an SCXML obj (stateMachine) for each as well
as executor?
public void reset() throws ModelException {
// Reset all variable contexts
stateMachine.getRootContext().reset();
// all states and parallels, only states have var. contexts
for (Iterator i = stateMachine.getTargets().values().iterator();
i.hasNext();) {
TransitionTarget tt = (TransitionTarget) i.next();
if (tt instanceof State) {
((State) tt).getContext().reset();
} else if (tt instanceof History) {
((History) tt).reset();
}
}
You mention "appropriately configured Executor" below. I wonder if you
suggest each Executor instance also has its own unique state machine
(SCXML obj) instance too. If so, I'm curious what implications this
would have on memory. We are sharing our SCXML after digesting, and
prevent cloning and use getInstance() for each Executor. Is this wrong?
Regards,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 13, 2005 12:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/12/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> Your code worked (from your personal snapshot) fine - thanks.
<snip/>
OK, thanks for the update :-)
> One issue
> we're now facing is handling concurrent users from multiple clients.
> My goal is to use one scxml doc to manage app flow for all users.
<snap/>
Indeed, there will usually be only one SCXML document for a particular
application task (or flow, or dialog) -- which could be of arbitrary
granularity -- yet the per user (or per session) "instances" of the
state machine must be able to execute independently.
> It looks
> like there is one context and it's shared, so if we trigger an event,
> it will affect any user.
<snip/>
Each user should have a separate Commons SCXML engine (or more
precisely, an instance of the org.apache.commons.scxml.SCXMLExecutor
class) assigned, and the events must be channeled to the appropriate
engine for the same user/session.
> We have created a HashMap (in memory) to store
> key/handle to client for sending response, but are having troubles
> dealing with concurrent users and their state.
>
> For example:
>
> Web request (state 1, event 3)
> IM request (state 2, event 1)
>
> Can the engine handle that or do you know how best to implement? My
> thought was to store state and last event per user, then navigate to
> that somehow for their requests. I assume there must be a better way?
>
<snap/>
We have a couple of published Commons SCXML usecases here:
http://jakarta.apache.org/commons/sandbox/scxml/usecases.html
Both the usecases are examples within a servlet container environment
(so similar to what you're attempting), and the SCXMLExecutor instance
gets created when needed, then cached and retrieved from the user's
session.
To summarize:
* A SCXML document describes the state machine for a task/flow/dialog
in an application.
* The org.apache.commons.scxml.model.SCXML class is the representation
of the document using the Commons SCXML Java object model.
* An appropriately configured SCXMLExecutor instance creates a "live"
state machine (or engine) upon which external events may be fired.
* SCXMLExecutor instances must be created per user/session and cached
throughout the life of the task/flow/dialog.
-Rahul
> Thanks,
>
>
> Mike
>
---------------------------------------------------------------------
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: [SCXML] Concurrent users
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/12/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> Your code worked (from your personal snapshot) fine - thanks.
<snip/>
OK, thanks for the update :-)
> One issue
> we're now facing is handling concurrent users from multiple clients. My
> goal is to use one scxml doc to manage app flow for all users.
<snap/>
Indeed, there will usually be only one SCXML document for a particular
application task (or flow, or dialog) -- which could be of arbitrary
granularity -- yet the per user (or per session) "instances" of the
state machine must be able to execute independently.
> It looks
> like there is one context and it's shared, so if we trigger an event, it
> will affect any user.
<snip/>
Each user should have a separate Commons SCXML engine (or more
precisely, an instance of the org.apache.commons.scxml.SCXMLExecutor
class) assigned, and the events must be channeled to the appropriate
engine for the same user/session.
> We have created a HashMap (in memory) to store
> key/handle to client for sending response, but are having troubles
> dealing with concurrent users and their state.
>
> For example:
>
> Web request (state 1, event 3)
> IM request (state 2, event 1)
>
> Can the engine handle that or do you know how best to implement? My
> thought was to store state and last event per user, then navigate to
> that somehow for their requests. I assume there must be a better way?
>
<snap/>
We have a couple of published Commons SCXML usecases here:
http://jakarta.apache.org/commons/sandbox/scxml/usecases.html
Both the usecases are examples within a servlet container environment
(so similar to what you're attempting), and the SCXMLExecutor instance
gets created when needed, then cached and retrieved from the user's
session.
To summarize:
* A SCXML document describes the state machine for a task/flow/dialog
in an application.
* The org.apache.commons.scxml.model.SCXML class is the
representation of the document using the Commons SCXML Java object
model.
* An appropriately configured SCXMLExecutor instance creates a "live"
state machine (or engine) upon which external events may be fired.
* SCXMLExecutor instances must be created per user/session and cached
throughout the life of the task/flow/dialog.
-Rahul
> Thanks,
>
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] Send
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
<snip/>
>
> I believe the EventDispatcher#send needs to have externalNodes added,
> and if you decide to add the getBodyContent, then perhaps a String
> bodyContent (not sure about that)? Do you allow method overloading in
> your Interfaces?
>
<snap/>
>
> Should the send method be (or just add these [overload])?:
>
> void send(String sendId, String target, String targetType,
> String event, Map params, Object hints, long delay,
> List externalNodes);
>
<snip/>
Yes, thats what it should be, thanks. Will make the change in a minute.
> void send(String sendId, String target, String targetType,
> String event, Map params, Object hints, long delay,
> List externalNodes, String bodyContent);
>
<snap/>
This, however, is mostly redundant. The users are free to do what they
need with the externalNodes (i.e. they can serialize those, if thats
what suits the particular task at hand -- which is probably what you
need to do for your purposes).
-Rahul
>
> /Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] EL and dynamic transition target
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Thanks Raul. So THAT'S what the W3C spec meant... :-) Makes sense, I
just didn't know you could have multiple transitions w/ same event
name.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 13, 2005 7:57 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] EL and dynamic transition target
On 12/13/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> One more query from my guy about our next step, getting EL to work:
>
> ============ HIS QUESTION
> "
>
> I tried various patterns to achieve to change the state based on guard
> condition, but the <transition><target> does not work. I manage to
> get the log "'IF Input was one'" etc on the selection, but the state
> remains in 'state_welcome'
>
> I am using the URL http://localhost:8080/goomzee/Voice for testing
> this.
>
>
> First box is for event, and second is for input. The 'event' need not
> be entered, based on the scxml, it is set to 'greet'
>
> <transition event="greet" >
> <var name="cb" expr="${ConversationBeanID}" />
> <var name="ip" expr="${cb.userInput}" />
> <var name="nextState" expr="state_welcome" />
>
> <log expr="'Input from cb was:' ${ip}" />
> <log expr="'Event from cb was:' ${cb.event}" />
> <if cond="${ip == 1}">
> <log expr="'IF Input was one'" />
> <assign name="nextState" expr="state_login" />
> <elseif cond="${ip == 2}" />
> <log expr="'IF Input was two'" />
> <assign name="nextState" expr="state_logoff" />
> <else />
> <log expr="'IF Other Input was :' ${ip} " />
> </if>
> <log expr="'Next State var :' ${nextState}" />
> <target next="${nextState}" />
> </transition>
>
> "
> =========== /HIS QUESTION
<snip/>
There is no such thing as a "dynamic" transition target in state chart
theory. One needs to enumerate all potential transition targets under
separate transitions. Guard conditions for transitions give us the
behavior you're looking for.
A state may have zero or more outbound transitions where each transition
specifies:
* A required target, specified at the time of authoring the state chart
* An optional event, which is the event or family of events which is
said to trigger a transition (i.e. make it part of the candidate
transitions set at any point in time)
* An optional guard condition, which must evaluate to "true" for a
particular transition to be followed.
* Any number of "executable actions" (such as <log>, <if> etc.) which
get processed *if and only if* the transition is followed.
Thus, the example above -- since it has two potential target states --
must be written out as the following (with <log> statements as
needed):
<transition event="greet" cond="${ConversationBeanID.userInput == 1}">
<target next="state_login" />
</transition>
<transition event="greet" cond="${ConversationBeanID.userInput == 2}">
<target next="state_logoff" />
</transition>
>
> MY INITIAL THOUGHT:
>
> perhaps within the conditional block, we add another transition:
>
> <if cond="${ip == 1}">
> <transition>
> <target next="state_logoff" />
> </transition>
> <else />
> ...
> </if>
>
> instead of assigning the variable and trying to execute at the end
> after evaluation? Do you know if our attempt above should work, or is
> the only way to implement by explicitly declaring the transition
> within the <if>...<else>...</if> blocks?
>
<snap/>
Actions are only meant to be executed onentry, ontransition or onexit,
i.e. as children of <onentry>, <transition> and <onexit> elements. Thus,
the <if>, <else> above are misplaced and will not have the desired
effect.
-Rahul
> Rgds,
>
> Mike
>
<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: [SCXML] EL and dynamic transition target
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/13/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> One more query from my guy about our next step, getting EL to work:
>
> ============ HIS QUESTION
> "
>
> I tried various patterns to achieve to change the state based on guard
> condition, but the <transition><target> does not work. I manage to get
> the log "'IF Input was one'" etc on the selection, but the state remains
> in 'state_welcome'
>
> I am using the URL http://localhost:8080/goomzee/Voice for testing this.
>
>
> First box is for event, and second is for input. The 'event' need not be
> entered, based on the scxml, it is set to 'greet'
>
> <transition event="greet" >
> <var name="cb" expr="${ConversationBeanID}" />
> <var name="ip" expr="${cb.userInput}" />
> <var name="nextState" expr="state_welcome" />
>
> <log expr="'Input from cb was:' ${ip}" />
> <log expr="'Event from cb was:' ${cb.event}" />
> <if cond="${ip == 1}">
> <log expr="'IF Input was one'" />
> <assign name="nextState" expr="state_login" />
> <elseif cond="${ip == 2}" />
> <log expr="'IF Input was two'" />
> <assign name="nextState" expr="state_logoff" />
> <else />
> <log expr="'IF Other Input was :' ${ip} " />
> </if>
> <log expr="'Next State var :' ${nextState}" />
> <target next="${nextState}" />
> </transition>
>
> "
> =========== /HIS QUESTION
<snip/>
There is no such thing as a "dynamic" transition target in state chart
theory. One needs to enumerate all potential transition targets under
separate transitions. Guard conditions for transitions give us the
behavior you're looking for.
A state may have zero or more outbound transitions where each
transition specifies:
* A required target, specified at the time of authoring the state chart
* An optional event, which is the event or family of events which is
said to trigger a transition (i.e. make it part of the candidate
transitions set at any point in time)
* An optional guard condition, which must evaluate to "true" for a
particular transition to be followed.
* Any number of "executable actions" (such as <log>, <if> etc.) which
get processed *if and only if* the transition is followed.
Thus, the example above -- since it has two potential target states --
must be written out as the following (with <log> statements as
needed):
<transition event="greet" cond="${ConversationBeanID.userInput == 1}">
<target next="state_login" />
</transition>
<transition event="greet" cond="${ConversationBeanID.userInput == 2}">
<target next="state_logoff" />
</transition>
>
> MY INITIAL THOUGHT:
>
> perhaps within the conditional block, we add another transition:
>
> <if cond="${ip == 1}">
> <transition>
> <target next="state_logoff" />
> </transition>
> <else />
> ...
> </if>
>
> instead of assigning the variable and trying to execute at the end after
> evaluation? Do you know if our attempt above should work, or is the
> only way to implement by explicitly declaring the transition within the
> <if>...<else>...</if> blocks?
>
<snap/>
Actions are only meant to be executed onentry, ontransition or onexit,
i.e. as children of <onentry>, <transition> and <onexit> elements.
Thus, the <if>, <else> above are misplaced and will not have the
desired effect.
-Rahul
> Rgds,
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Send
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
I agree to think about getBodyContent. Perhaps just best to interate
and populate StringBuffer and return String of contents, without DOM,
XMLSerialize, Element (and Xerces, etc dependencies). This way we can
choose how we parse/handle the contents. As long as it's well-formed,
spacing/formatting shouldn't matter, perhaps just add the "\n" and
that's it?
===
I believe the EventDispatcher#send needs to have externalNodes added,
and if you decide to add the getBodyContent, then perhaps a String
bodyContent (not sure about that)? Do you allow method overloading in
your Interfaces?
====
public interface EventDispatcher {
/**
* Cancel the specified send message.
*
* @param sendId The ID of the send message to cancel
*/
void cancel(String sendId);
/**
* Send this message to the target.
*
* @param sendId The ID of the send message
* @param target An expression returning the target location of the
event
* @param targetType The type of the Event I/O Processor that the
event
* should be dispatched to
* @param event The type of event being generated.
* @param params A list of zero or more whitespace separated
variable
* names to be included with the event.
* @param hints The data containing information which may be
* used by the implementing platform to configure the event
processor
* @param delay The event is dispatched after the delay interval
elapses
*/
void send(String sendId, String target, String targetType,
String event, Map params, Object hints, long delay);
}
====
Should the send method be (or just add these [overload])?:
void send(String sendId, String target, String targetType,
String event, Map params, Object hints, long delay,
List externalNodes);
void send(String sendId, String target, String targetType,
String event, Map params, Object hints, long delay,
List externalNodes, String bodyContent);
/Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 13, 2005 12:44 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/13/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I think build may have broke due to dependency on XercesImpl,
> xml-apis, and possibly xalan jar dependencies. Your recent code
> change likely requires them now so you may update the dependencies and
> jars to your build.xml, plus the docs.
<snip/>
Yes, I revisited this yesterday. At this point, I'm not happy declaring
those dependencies, so I left a comment in the code and removed the
recently added utility method Send#getBodyContent(). The details of the
related change are here:
http://svn.apache.org/viewcvs.cgi?rev=356390&view=rev
It seems the Commons nightlies didn't build today (none of the projects
were built) so today's failure seems unrelated.
> Also, we noticed that the context vars return
> null within onentry and can only be retrieved during ontransition.
> I'm not sure if just our implementation or how it's built. Anyhow,
> just a little input from our findings.
>
<snap/>
Umm, that doesn't sound right. If you can produce the smallest possible
test document that demonstrates this, I'll be happy to take a look.
-Rahul
> Rgds,
>
> Mike
>
<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
[SCXML] EL and dynamic transition target
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
One more query from my guy about our next step, getting EL to work:
============ HIS QUESTION
"
I tried various patterns to achieve to change the state based on guard
condition, but the <transition><target> does not work. I manage to get
the log "'IF Input was one'" etc on the selection, but the state remains
in 'state_welcome'
I am using the URL http://localhost:8080/goomzee/Voice for testing this.
First box is for event, and second is for input. The 'event' need not be
entered, based on the scxml, it is set to 'greet'
<transition event="greet" >
<var name="cb" expr="${ConversationBeanID}" />
<var name="ip" expr="${cb.userInput}" />
<var name="nextState" expr="state_welcome" />
<log expr="'Input from cb was:' ${ip}" />
<log expr="'Event from cb was:' ${cb.event}" />
<if cond="${ip == 1}">
<log expr="'IF Input was one'" />
<assign name="nextState" expr="state_login" />
<elseif cond="${ip == 2}" />
<log expr="'IF Input was two'" />
<assign name="nextState" expr="state_logoff" />
<else />
<log expr="'IF Other Input was :' ${ip} " />
</if>
<log expr="'Next State var :' ${nextState}" />
<target next="${nextState}" />
</transition>
"
=========== /HIS QUESTION
MY INITIAL THOUGHT:
perhaps within the conditional block, we add another transition:
<if cond="${ip == 1}">
<transition>
<target next="state_logoff" />
</transition>
<else />
...
</if>
instead of assigning the variable and trying to execute at the end after
evaluation? Do you know if our attempt above should work, or is the
only way to implement by explicitly declaring the transition within the
<if>...<else>...</if> blocks?
Rgds,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 13, 2005 12:44 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/13/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I think build may have broke due to dependency on XercesImpl,
> xml-apis, and possibly xalan jar dependencies. Your recent code
> change likely requires them now so you may update the dependencies and
> jars to your build.xml, plus the docs.
<snip/>
Yes, I revisited this yesterday. At this point, I'm not happy declaring
those dependencies, so I left a comment in the code and removed the
recently added utility method Send#getBodyContent(). The details of the
related change are here:
http://svn.apache.org/viewcvs.cgi?rev=356390&view=rev
It seems the Commons nightlies didn't build today (none of the projects
were built) so today's failure seems unrelated.
> Also, we noticed that the context vars return
> null within onentry and can only be retrieved during ontransition.
> I'm not sure if just our implementation or how it's built. Anyhow,
> just a little input from our findings.
>
<snap/>
Umm, that doesn't sound right. If you can produce the smallest possible
test document that demonstrates this, I'll be happy to take a look.
-Rahul
> Rgds,
>
> Mike
>
<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: [SCXML] Concurrent users
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/13/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I think build may have broke due to dependency on XercesImpl, xml-apis,
> and possibly xalan jar dependencies. Your recent code change likely
> requires them now so you may update the dependencies and jars to your
> build.xml, plus the docs.
<snip/>
Yes, I revisited this yesterday. At this point, I'm not happy
declaring those dependencies, so I left a comment in the code and
removed the recently added utility method Send#getBodyContent(). The
details of the related change are here:
http://svn.apache.org/viewcvs.cgi?rev=356390&view=rev
It seems the Commons nightlies didn't build today (none of the
projects were built) so today's failure seems unrelated.
> Also, we noticed that the context vars return
> null within onentry and can only be retrieved during ontransition. I'm
> not sure if just our implementation or how it's built. Anyhow, just a
> little input from our findings.
>
<snap/>
Umm, that doesn't sound right. If you can produce the smallest
possible test document that demonstrates this, I'll be happy to take a
look.
-Rahul
> Rgds,
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
I think build may have broke due to dependency on XercesImpl, xml-apis,
and possibly xalan jar dependencies. Your recent code change likely
requires them now so you may update the dependencies and jars to your
build.xml, plus the docs. Also, we noticed that the context vars return
null within onentry and can only be retrieved during ontransition. I'm
not sure if just our implementation or how it's built. Anyhow, just a
little input from our findings.
Rgds,
Mike
-----Original Message-----
From: Mike Sparr - www.goomzee.com [mailto:mike@goomzee.com]
Sent: Monday, December 12, 2005 9:24 PM
To: 'Jakarta Commons Users List'
Subject: [SCXML] Concurrent users
Rahul,
Your code worked (from your personal snapshot) fine - thanks. One issue
we're now facing is handling concurrent users from multiple clients. My
goal is to use one scxml doc to manage app flow for all users. It looks
like there is one context and it's shared, so if we trigger an event, it
will affect any user. We have created a HashMap (in memory) to store
key/handle to client for sending response, but are having troubles
dealing with concurrent users and their state.
For example:
Web request (state 1, event 3)
IM request (state 2, event 1)
Can the engine handle that or do you know how best to implement? My
thought was to store state and last event per user, then navigate to
that somehow for their requests. I assume there must be a better way?
Thanks,
Mike
---------------------------------------------------------------------
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
[SCXML] Concurrent users
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
Your code worked (from your personal snapshot) fine - thanks. One issue
we're now facing is handling concurrent users from multiple clients. My
goal is to use one scxml doc to manage app flow for all users. It looks
like there is one context and it's shared, so if we trigger an event, it
will affect any user. We have created a HashMap (in memory) to store
key/handle to client for sending response, but are having troubles
dealing with concurrent users and their state.
For example:
Web request (state 1, event 3)
IM request (state 2, event 1)
Can the engine handle that or do you know how best to implement? My
thought was to store state and last event per user, then navigate to
that somehow for their requests. I assume there must be a better way?
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] Help with SCXML Send usage
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/12/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> Binary for 1211 is corrupt, ZIP version didn't upload and GZ is only
> 45k? Can you check that and if you get a build to work, any chance
> email binary to me (ZIP or GZ ok). We tried to build the source which
> appears okay, but don't have Maven, etc. If you can check that binary
> I'd appreciate it.
>
<snip/>
Yes, I noticed the failures. I try not to break the build, not sure
what caused that. If it continues to fail for another day or two, I'll
ask.
I'd highly recommend being able to build if you're working with the
latest code. It'd be unfortunate if you lost time because the nightly
failed. Please take a few minutes to download a svn client [1] to grab
the source and either ant [2] or maven (1.0.2) [3] to build (do a 'ant
jar' or 'maven jar').
You can find today's snapshot jar (built on my machine) at the following URL:
http://people.apache.org/~rahul/snapshots/
-Rahul
[1] http://subversion.tigris.org/ (scroll down for clients under 'scm'
category in left side nav bar)
[2] http://ant.apache.org/
[3] http://maven.apache.org/
> http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
>
> Cheers,
>
>
> Mike
>
>
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Saturday, December 10, 2005 5:03 PM
> To: Jakarta Commons Users List
> Subject: Re: [SCXML] Help with SCXML Send usage
>
>
> On 12/10/05, Rahul Akolkar <ra...@gmail.com> wrote: <snip/>
> >
> > On 12/10/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> > > Rahul,
> > >
> > > I haven't compiled/tested, but it looks like this (below) is what is
>
> > > needed in the SCXMLDigester.java? Is there any way for you to
> > > verify and perhaps rebuild the binary - I don't want to stray too
> > > far from your codebase. :-)
> > >
> > <snip/>
> >
> > Yup, something similar :-) I'm going to take a stab at that today.
> > I'll ping this thread when I make some progress.
> >
> <snap/>
>
> Mike -
>
> I've made some changes in r355810 [1] which will now cause the external
> nodes to be populated in the Send instance. I've added a utility method
> Send#getBodyContent() to obtain the serialized body content. A test case
> was added in the same commit which might be useful in terms of spotting
> the changes.
>
> You'll need to implement the SCXML EventDispatcher interface to do the
> necessary marshalling of the body content markup to suit your needs.
>
> This should be reflected in the 12112005 nightly binaries, which will be
> available here [2] tomorrow.
>
> -Rahul
>
> [1] http://svn.apache.org/viewcvs.cgi?rev=355810&view=rev
> [2] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Help with SCXML Send usage
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
Binary for 1211 is corrupt, ZIP version didn't upload and GZ is only
45k? Can you check that and if you get a build to work, any chance
email binary to me (ZIP or GZ ok). We tried to build the source which
appears okay, but don't have Maven, etc. If you can check that binary
I'd appreciate it.
http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Saturday, December 10, 2005 5:03 PM
To: Jakarta Commons Users List
Subject: Re: [SCXML] Help with SCXML Send usage
On 12/10/05, Rahul Akolkar <ra...@gmail.com> wrote: <snip/>
>
> On 12/10/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> > Rahul,
> >
> > I haven't compiled/tested, but it looks like this (below) is what is
> > needed in the SCXMLDigester.java? Is there any way for you to
> > verify and perhaps rebuild the binary - I don't want to stray too
> > far from your codebase. :-)
> >
> <snip/>
>
> Yup, something similar :-) I'm going to take a stab at that today.
> I'll ping this thread when I make some progress.
>
<snap/>
Mike -
I've made some changes in r355810 [1] which will now cause the external
nodes to be populated in the Send instance. I've added a utility method
Send#getBodyContent() to obtain the serialized body content. A test case
was added in the same commit which might be useful in terms of spotting
the changes.
You'll need to implement the SCXML EventDispatcher interface to do the
necessary marshalling of the body content markup to suit your needs.
This should be reflected in the 12112005 nightly binaries, which will be
available here [2] tomorrow.
-Rahul
[1] http://svn.apache.org/viewcvs.cgi?rev=355810&view=rev
[2] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
---------------------------------------------------------------------
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: [SCXML] Help with SCXML Send usage
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
I'm new to the mailing list phenonemon so please excuse my ingorance - I
navigate forums with the best of them - just let me know what I need to
do (reply-to issue).
I will check out your solution and appreciate you taking the time to add
that "feature" - hopefully I wasn't too far off ;-). We'll download
tomorrow and I'll queue up revisiting that functionality when we begin
again Sunday night (here in Montana) and (Monday AM IST).
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Saturday, December 10, 2005 5:03 PM
To: Jakarta Commons Users List
Subject: Re: [SCXML] Help with SCXML Send usage
On 12/10/05, Rahul Akolkar <ra...@gmail.com> wrote: <snip/>
>
> On 12/10/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> > Rahul,
> >
> > I haven't compiled/tested, but it looks like this (below) is what is
> > needed in the SCXMLDigester.java? Is there any way for you to
> > verify and perhaps rebuild the binary - I don't want to stray too
> > far from your codebase. :-)
> >
> <snip/>
>
> Yup, something similar :-) I'm going to take a stab at that today.
> I'll ping this thread when I make some progress.
>
<snap/>
Mike -
I've made some changes in r355810 [1] which will now cause the external
nodes to be populated in the Send instance. I've added a utility method
Send#getBodyContent() to obtain the serialized body content. A test case
was added in the same commit which might be useful in terms of spotting
the changes.
You'll need to implement the SCXML EventDispatcher interface to do the
necessary marshalling of the body content markup to suit your needs.
This should be reflected in the 12112005 nightly binaries, which will be
available here [2] tomorrow.
-Rahul
[1] http://svn.apache.org/viewcvs.cgi?rev=355810&view=rev
[2] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
---------------------------------------------------------------------
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: [SCXML] Help with SCXML Send usage
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/10/05, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
>
> On 12/10/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> > Rahul,
> >
> > I haven't compiled/tested, but it looks like this (below) is what is
> > needed in the SCXMLDigester.java? Is there any way for you to verify
> > and perhaps rebuild the binary - I don't want to stray too far from your
> > codebase. :-)
> >
> <snip/>
>
> Yup, something similar :-) I'm going to take a stab at that today.
> I'll ping this thread when I make some progress.
>
<snap/>
Mike -
I've made some changes in r355810 [1] which will now cause the
external nodes to be populated in the Send instance. I've added a
utility method Send#getBodyContent() to obtain the serialized body
content. A test case was added in the same commit which might be
useful in terms of spotting the changes.
You'll need to implement the SCXML EventDispatcher interface to do the
necessary marshalling of the body content markup to suit your needs.
This should be reflected in the 12112005 nightly binaries, which will
be available here [2] tomorrow.
-Rahul
[1] http://svn.apache.org/viewcvs.cgi?rev=355810&view=rev
[2] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] Help with SCXML Send usage
Posted by Rahul Akolkar <ra...@gmail.com>.
Hi Mike -
The Reply-To header for your emails gets set to your email address
(rather than the mailing list) so my last email went to you rather
than the list. Do you have control over that?
On 12/10/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I haven't compiled/tested, but it looks like this (below) is what is
> needed in the SCXMLDigester.java? Is there any way for you to verify
> and perhaps rebuild the binary - I don't want to stray too far from your
> codebase. :-)
>
<snip/>
Yup, something similar :-) I'm going to take a stab at that today.
I'll ping this thread when I make some progress.
If you're interested, here is what you'll need to build your own
Commons SCXML nightlies (any Commons component in general):
* A subversion (SVN) client (to grab the latest code)
* Ant (1.6.x is good) or Maven (1.0.2)
-Rahul
>
> /**
> * Add Digester rules for all actions ("executable"
> elements).
> *
> * @param xp The Digester style XPath expression of the parent
> * XML element
> * @param scxmlRules The rule set to be used for digestion
> */
> private static void addActionRules(final String xp,
> final ExtendedBaseRules scxmlRules) {
> addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
> addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
> addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
> addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
>
> // add digestion of send element contents (these components
> needed I think)
> scxmlDigester.setNamespaceAware(true);
> scxmlDigester.setRuleNamespaceURI(null);
> scxmlRules.add(xp + XP_SND, new
> NodeCreateRule(Node.DOCUMENT_FRAGMENT_NODE));
> scxmlDigester.addSetNext(xp + XP_SND, "setExternalNodes",
> ArrayList.class);
> // end add nested digestion rules
>
> addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
> addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
> }
>
>
> Your Send class has an ArrayList externalNodes which I assume you meant
> for that purpose (storing nexted elements). If I'm mistaken, please let
> me know. Anyhow, with this code above, perhaps you want to "clean up"
> using your ...Tuple(...) method???
>
> If you have time, the middle section code is what I think we need to add
> to "digest" the contents within the <send>...</send> tags. Please let
> me know if you update the SCXMLDigester and what binary to download to
> test (assuming you have time to add this).
>
> Finally, the W3C spec for <send> states that either the tag attributes
> OR the nested elements are mutually exclusive. I like your
> implementation and think we're better served by allowing both attributes
> within the <send target="" namelist="" ...>and nested content</send>.
> Your thoughts?
>
>
> Resources:
> -
> http://rzm-hamy-wsx.rz.uni-karlsruhe.de/External/Documents-Mirrored/Java
> /mirror/jakarta-commons-digester-1.4.1-src/src/test/org/apache/commons/d
> igester/NodeCreateRuleTestCase.java (see testNested() and
> testNamespaces() methods
>
> - http://www-128.ibm.com/developerworks/java/library/j-lucene/
> (example Digester with addSetNext to call method after closing tag???)
>
> -
> http://jakarta.apache.org/commons/digester/xref/org/apache/commons/diges
> ter/Digester.html#2360 (addSetNext source)
>
>
>
> Mike
>
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Digester] assistance - namespace-aware processing (how to
write rules for digest)
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-12-10 at 02:23 -0700, Mike Sparr - www.goomzee.com wrote:
> If I have a document (note the content element referencing external
> namespace):
>
> <document>
> <author name="John Doe" />
> <title>Some name of a document</title>
> <exerpt>A brief description of a quotable phrase from
> document</exerpt>
> <content xmlns:myco="http://www.company.com/document/schema">
> <myco:heading>This is the heading of the document</myco:heading>
> <myco:sub-heading>This is the sub-heading of the
> document</myco:sub-heading>
> <myco:body>
> This is the body content of the document
> and I can have some text that references a
> term that may require more explaination so
> I add a strangeword<myco:footnote symbol="*" expr="refer to user
> guide for more information" /> and this footnote will appear at
> the bottom of the document.
> </myco:body>
> </content>
> </document>
>
> I am new to digester but understand I have to write getter/setter
> classes to represent the different elements. Can someone help with
> writing the rules to digest this? I would like some flexibility to have
> zero, one or more namespaces declared in my <content> element and the
> digester will "digest" the elements within these.
>
> For example, this instance uses a namespace and scheme defined by myco,
> but we may want just text with no namespaces, or use
> xmlns:xhtml="http://www.w3.org/xhtml/schema" and embed html in the
> document.
>
> Where do I start?
There are a number of good resources for learning Digester.
There is a list of articles availabel on the wiki:
http://wiki.apache.org/jakarta-commons/Digester/ArticlesAndTutorials
There is a general overview of digester in the javadoc:
http://jakarta.apache.org/commons/digester/commons-digester-1.7/docs/api/org/apache/commons/digester/package-summary.html
There are also a number of example applications available. They are
included in the source downloads for digester, or can be browsed
directly from the subversion repository:
http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/trunk/src/examples/
Note that Digester's support for xml namespaces is quite weak; it was
originally written before namespaces existed and that shows. A rule can
be associated with a namespace; this ensures that the *last* element in
the match path is in the specified namespace. However there is no
control over namespace-matching for the other parts of the path. As am
example, a rule with path "foo/bar/baz" and namespace "urn:ns1" will
only match baz elements in the specified namespace, but foo and bar will
match elements in any namespace. This looks like it will be acceptable
for your purposes though.
Once you have read the available info, I'm happy to answer any specific
questions you may have...
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[Digester] assistance - namespace-aware processing (how to write rules for digest)
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
If I have a document (note the content element referencing external
namespace):
<document>
<author name="John Doe" />
<title>Some name of a document</title>
<exerpt>A brief description of a quotable phrase from
document</exerpt>
<content xmlns:myco="http://www.company.com/document/schema">
<myco:heading>This is the heading of the document</myco:heading>
<myco:sub-heading>This is the sub-heading of the
document</myco:sub-heading>
<myco:body>
This is the body content of the document
and I can have some text that references a
term that may require more explaination so
I add a strangeword<myco:footnote symbol="*" expr="refer to user
guide for more information" /> and this footnote will appear at
the bottom of the document.
</myco:body>
</content>
</document>
I am new to digester but understand I have to write getter/setter
classes to represent the different elements. Can someone help with
writing the rules to digest this? I would like some flexibility to have
zero, one or more namespaces declared in my <content> element and the
digester will "digest" the elements within these.
For example, this instance uses a namespace and scheme defined by myco,
but we may want just text with no namespaces, or use
xmlns:xhtml="http://www.w3.org/xhtml/schema" and embed html in the
document.
Where do I start?
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] Help with SCXML Send usage
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
I haven't compiled/tested, but it looks like this (below) is what is
needed in the SCXMLDigester.java? Is there any way for you to verify
and perhaps rebuild the binary - I don't want to stray too far from your
codebase. :-)
/**
* Add Digester rules for all actions ("executable"
elements).
*
* @param xp The Digester style XPath expression of the parent
* XML element
* @param scxmlRules The rule set to be used for digestion
*/
private static void addActionRules(final String xp,
final ExtendedBaseRules scxmlRules) {
addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
// add digestion of send element contents (these components
needed I think)
scxmlDigester.setNamespaceAware(true);
scxmlDigester.setRuleNamespaceURI(null);
scxmlRules.add(xp + XP_SND, new
NodeCreateRule(Node.DOCUMENT_FRAGMENT_NODE));
scxmlDigester.addSetNext(xp + XP_SND, "setExternalNodes",
ArrayList.class);
// end add nested digestion rules
addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
}
Your Send class has an ArrayList externalNodes which I assume you meant
for that purpose (storing nexted elements). If I'm mistaken, please let
me know. Anyhow, with this code above, perhaps you want to "clean up"
using your ...Tuple(...) method???
If you have time, the middle section code is what I think we need to add
to "digest" the contents within the <send>...</send> tags. Please let
me know if you update the SCXMLDigester and what binary to download to
test (assuming you have time to add this).
Finally, the W3C spec for <send> states that either the tag attributes
OR the nested elements are mutually exclusive. I like your
implementation and think we're better served by allowing both attributes
within the <send target="" namelist="" ...>and nested content</send>.
Your thoughts?
Resources:
-
http://rzm-hamy-wsx.rz.uni-karlsruhe.de/External/Documents-Mirrored/Java
/mirror/jakarta-commons-digester-1.4.1-src/src/test/org/apache/commons/d
igester/NodeCreateRuleTestCase.java (see testNested() and
testNamespaces() methods
- http://www-128.ibm.com/developerworks/java/library/j-lucene/
(example Digester with addSetNext to call method after closing tag???)
-
http://jakarta.apache.org/commons/digester/xref/org/apache/commons/diges
ter/Digester.html#2360 (addSetNext source)
Mike
-----Original Message-----
From: Mike Sparr - www.goomzee.com [mailto:mike@goomzee.com]
Sent: Tuesday, December 06, 2005 5:44 PM
To: 'Rahul Akolkar'; 'Jakarta Commons Users List'
Subject: RE: [SCXML] Help with SCXML Send usage
Hi Rahul,
I appreciate the direction and if we get the <send> contents </send>
code working, I'll send it to you to choose what you want to
incorporate, or tell me what we did wrong more likely. :-). I'm hoping
to build a useful tool for a specific purpose but aim to design it
flexible enough that we can extend in the future as a multimodal
enabler.
I would like to keep in touch and contribute where I can. If you
haven't seen yet, visit this link:
http://www.w3.org/2005/Talks/1111-maxf-delhi/
I think the big boys are waiting for the maturity of this to spec out
the browsers of the future (built-in to clients like GPS devices,
phones, pdas, etc.). You've done a great job and I do hope to build
upon that and increase the audience.
I also have another developer working locally helping me publish and
subscribe to a web service, exposing some useful public data. I will
publish this service and provide all source code for free with tutorials
to teach others how to write, publish and subscribe to web services. I
can share that with you when ready too.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 06, 2005 2:28 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Help with SCXML Send usage
On 12/6/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I appreciate your response. Yes, I did look at RDC and it does not
> meet my needs. Your musicstore app required you to write two separate
> pages (one for GUI, one for voice) although yes, you did get to reuse
> the dialog and leverage your tags.
>
> What I want is to have a single input (String) and output (XSL
> formatted
> String) and a single file that defines our conversation. Essentially
if
> I deploy a client plug-in, it will transform whatever input received
> into my single input and pass to my app, along with client type and
> handle. My app will process the input based on conversation rules
> defined in SCXML and ultimately return a formatted string using XSL
for
> that particular client.
>
> I don't want to write JSPs for each, but rather have a single
> input/output defined and write my app flow and logic using SCXML/VXML.
>
<snip/>
Sure, my intent wasn't to thrust another technology (JSP) or another
framework (RDC) upon you, but to indicate what I think is a path of
least resistance for *scalable* applications using building blocks
available at Apache right this moment. And that is probably important
given that you're paying by the hour. Using the RDC template [1], things
should be fairly straightforward. Having said that, lets move the
discussion to where you (and some of us as well) would like to be i.e. a
compound document that supports VoiceXML snippets in the body of the
SCXML <send>.
> The SCXML spec: http://www.w3.org/TR/2005/WD-scxml-20050705/#N104B9
>
> This shows that you can declare a namespace and embed tags within the
> Send element. Given vxml is structured for dialog, I hope to use it
> in defining my "screens" using <form> and <menu> and letting XSL
> format it for that particular client.
>
> It's pretty simple, just need help getting the contents of Send. I am
> paying a developer to help me so every hour is costing me... Ouch. Any
> help you can provide, even a quick/dirty example of adding some rules
> would be a great help.
>
> If you could tell me what to add, I can have my "helper" add it for
> our purpose. My guess is either modify line 264:
>
> "/send"
> to
> "/send/form/block/prompt"
>
> - I'm unfamiliar with how this works?
>
> I assume then some modification to after line 579 in
> SCXMLDigester.java:
>
<snap/>
Mike, check out the SCXML source Xref [2] which allows to point / link
to line numbers in code. Line 264 for SCXMLDigester [3] seems to lead
somewhere other than what you mention, so does like 579. In any case,
I'd recommend that anyone working with this code read up on Commons
Digester, you'll find much information on the digester website [4] and
wiki [5]. Specifically, I'd look up the NodeCreateRule I pointed to
yesterday to grab all content under the <send> and on getting the onSend
callback on the EventDispatcher, marshall the VoiceXML bits to the voice
browser. On the way back, you'll need to get the value specified by the
user, and make it available in the context of execution for the
SCXMLExecutor, and the easiest way to do that is to do a
Context#set(String,Object) on the RootContext, which may be accessed
using scxmlExecutor.getStateMachine().getRootContext(). The user's input
is now available to be part of the decision making for the next logical
outcome.
The RDC framework does something similar under the hood to enable
plugging SCXML controllers.
> /**
> * Add Digester rules for all actions ("executable"
> elements).
> *
> * @param xp The Digester style XPath expression of the parent
> * XML element
> * @param scxmlRules The rule set to be used for digestion
> */
> private static void addActionRules(final String xp,
> final ExtendedBaseRules scxmlRules) {
> addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
> addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
> addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
> addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
<snip/>
The digester processing in the line above will need to change to grab
arbitrary external namespace children. I still need to look at digester
closely in the realm of multiple namespaces (probably will this
weekend), but a NodeCreateRule seems like the best bet here (or search
the commons-user / dev archives for similar questions).
> addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
> addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
> }
>
> Any help or just some sample code how to modify would be a great help!
>
<snap/>
Once you get this bit going, that'd be quite a nice demonstration of
SCXML. If you're so inclined, I'd suggest thinking about contributing
back to the Commons SCXML community so the enhancements you've made are
available to the rest of us.
-Rahul
[1]
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorial
s/RDCTemplate
[2] http://jakarta.apache.org/commons/sandbox/scxml/xref/index.html
[3]
http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/
scxml/SCXMLDigester.html#264
[4] http://jakarta.apache.org/commons/digester/
[5] http://wiki.apache.org/jakarta-commons/Digester
> Thanks,
>
>
> Mike
>
<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: [SCXML] Help with SCXML Send usage
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Hi Rahul,
I appreciate the direction and if we get the <send> contents </send>
code working, I'll send it to you to choose what you want to
incorporate, or tell me what we did wrong more likely. :-). I'm hoping
to build a useful tool for a specific purpose but aim to design it
flexible enough that we can extend in the future as a multimodal
enabler.
I would like to keep in touch and contribute where I can. If you
haven't seen yet, visit this link:
http://www.w3.org/2005/Talks/1111-maxf-delhi/
I think the big boys are waiting for the maturity of this to spec out
the browsers of the future (built-in to clients like GPS devices,
phones, pdas, etc.). You've done a great job and I do hope to build
upon that and increase the audience.
I also have another developer working locally helping me publish and
subscribe to a web service, exposing some useful public data. I will
publish this service and provide all source code for free with tutorials
to teach others how to write, publish and subscribe to web services. I
can share that with you when ready too.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 06, 2005 2:28 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Help with SCXML Send usage
On 12/6/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I appreciate your response. Yes, I did look at RDC and it does not
> meet my needs. Your musicstore app required you to write two separate
> pages (one for GUI, one for voice) although yes, you did get to reuse
> the dialog and leverage your tags.
>
> What I want is to have a single input (String) and output (XSL
> formatted
> String) and a single file that defines our conversation. Essentially
if
> I deploy a client plug-in, it will transform whatever input received
> into my single input and pass to my app, along with client type and
> handle. My app will process the input based on conversation rules
> defined in SCXML and ultimately return a formatted string using XSL
for
> that particular client.
>
> I don't want to write JSPs for each, but rather have a single
> input/output defined and write my app flow and logic using SCXML/VXML.
>
<snip/>
Sure, my intent wasn't to thrust another technology (JSP) or another
framework (RDC) upon you, but to indicate what I think is a path of
least resistance for *scalable* applications using building blocks
available at Apache right this moment. And that is probably important
given that you're paying by the hour. Using the RDC template [1], things
should be fairly straightforward. Having said that, lets move the
discussion to where you (and some of us as well) would like to be i.e. a
compound document that supports VoiceXML snippets in the body of the
SCXML <send>.
> The SCXML spec: http://www.w3.org/TR/2005/WD-scxml-20050705/#N104B9
>
> This shows that you can declare a namespace and embed tags within the
> Send element. Given vxml is structured for dialog, I hope to use it
> in defining my "screens" using <form> and <menu> and letting XSL
> format it for that particular client.
>
> It's pretty simple, just need help getting the contents of Send. I am
> paying a developer to help me so every hour is costing me... Ouch. Any
> help you can provide, even a quick/dirty example of adding some rules
> would be a great help.
>
> If you could tell me what to add, I can have my "helper" add it for
> our purpose. My guess is either modify line 264:
>
> "/send"
> to
> "/send/form/block/prompt"
>
> - I'm unfamiliar with how this works?
>
> I assume then some modification to after line 579 in
> SCXMLDigester.java:
>
<snap/>
Mike, check out the SCXML source Xref [2] which allows to point / link
to line numbers in code. Line 264 for SCXMLDigester [3] seems to lead
somewhere other than what you mention, so does like 579. In any case,
I'd recommend that anyone working with this code read up on Commons
Digester, you'll find much information on the digester website [4] and
wiki [5]. Specifically, I'd look up the NodeCreateRule I pointed to
yesterday to grab all content under the <send> and on getting the onSend
callback on the EventDispatcher, marshall the VoiceXML bits to the voice
browser. On the way back, you'll need to get the value specified by the
user, and make it available in the context of execution for the
SCXMLExecutor, and the easiest way to do that is to do a
Context#set(String,Object) on the RootContext, which may be accessed
using scxmlExecutor.getStateMachine().getRootContext(). The user's input
is now available to be part of the decision making for the next logical
outcome.
The RDC framework does something similar under the hood to enable
plugging SCXML controllers.
> /**
> * Add Digester rules for all actions ("executable"
> elements).
> *
> * @param xp The Digester style XPath expression of the parent
> * XML element
> * @param scxmlRules The rule set to be used for digestion
> */
> private static void addActionRules(final String xp,
> final ExtendedBaseRules scxmlRules) {
> addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
> addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
> addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
> addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
<snip/>
The digester processing in the line above will need to change to grab
arbitrary external namespace children. I still need to look at digester
closely in the realm of multiple namespaces (probably will this
weekend), but a NodeCreateRule seems like the best bet here (or search
the commons-user / dev archives for similar questions).
> addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
> addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
> }
>
> Any help or just some sample code how to modify would be a great help!
>
<snap/>
Once you get this bit going, that'd be quite a nice demonstration of
SCXML. If you're so inclined, I'd suggest thinking about contributing
back to the Commons SCXML community so the enhancements you've made are
available to the rest of us.
-Rahul
[1]
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorial
s/RDCTemplate
[2] http://jakarta.apache.org/commons/sandbox/scxml/xref/index.html
[3]
http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/
scxml/SCXMLDigester.html#264
[4] http://jakarta.apache.org/commons/digester/
[5] http://wiki.apache.org/jakarta-commons/Digester
> Thanks,
>
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] Help with SCXML Send usage
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/6/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> I appreciate your response. Yes, I did look at RDC and it does not meet
> my needs. Your musicstore app required you to write two separate pages
> (one for GUI, one for voice) although yes, you did get to reuse the
> dialog and leverage your tags.
>
> What I want is to have a single input (String) and output (XSL formatted
> String) and a single file that defines our conversation. Essentially if
> I deploy a client plug-in, it will transform whatever input received
> into my single input and pass to my app, along with client type and
> handle. My app will process the input based on conversation rules
> defined in SCXML and ultimately return a formatted string using XSL for
> that particular client.
>
> I don't want to write JSPs for each, but rather have a single
> input/output defined and write my app flow and logic using SCXML/VXML.
>
<snip/>
Sure, my intent wasn't to thrust another technology (JSP) or another
framework (RDC) upon you, but to indicate what I think is a path of
least resistance for *scalable* applications using building blocks
available at Apache right this moment. And that is probably important
given that you're paying by the hour. Using the RDC template [1],
things should be fairly straightforward. Having said that, lets move
the discussion to where you (and some of us as well) would like to be
i.e. a compound document that supports VoiceXML snippets in the body
of the SCXML <send>.
> The SCXML spec:
> http://www.w3.org/TR/2005/WD-scxml-20050705/#N104B9
>
> This shows that you can declare a namespace and embed tags within the
> Send element. Given vxml is structured for dialog, I hope to use it in
> defining my "screens" using <form> and <menu> and letting XSL format it
> for that particular client.
>
> It's pretty simple, just need help getting the contents of Send. I am
> paying a developer to help me so every hour is costing me... Ouch. Any
> help you can provide, even a quick/dirty example of adding some rules
> would be a great help.
>
> If you could tell me what to add, I can have my "helper" add it for our
> purpose. My guess is either modify line 264:
>
> "/send"
> to
> "/send/form/block/prompt"
>
> - I'm unfamiliar with how this works?
>
> I assume then some modification to after line 579 in SCXMLDigester.java:
>
<snap/>
Mike, check out the SCXML source Xref [2] which allows to point / link
to line numbers in code. Line 264 for SCXMLDigester [3] seems to lead
somewhere other than what you mention, so does like 579. In any case,
I'd recommend that anyone working with this code read up on Commons
Digester, you'll find much information on the digester website [4] and
wiki [5]. Specifically, I'd look up the NodeCreateRule I pointed to
yesterday to grab all content under the <send> and on getting the
onSend callback on the EventDispatcher, marshall the VoiceXML bits to
the voice browser. On the way back, you'll need to get the value
specified by the user, and make it available in the context of
execution for the SCXMLExecutor, and the easiest way to do that is to
do a Context#set(String,Object) on the RootContext, which may be
accessed using scxmlExecutor.getStateMachine().getRootContext(). The
user's input is now available to be part of the decision making for
the next logical outcome.
The RDC framework does something similar under the hood to enable
plugging SCXML controllers.
> /**
> * Add Digester rules for all actions ("executable"
> elements).
> *
> * @param xp The Digester style XPath expression of the parent
> * XML element
> * @param scxmlRules The rule set to be used for digestion
> */
> private static void addActionRules(final String xp,
> final ExtendedBaseRules scxmlRules) {
> addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
> addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
> addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
> addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
<snip/>
The digester processing in the line above will need to change to grab
arbitrary external namespace children. I still need to look at
digester closely in the realm of multiple namespaces (probably will
this weekend), but a NodeCreateRule seems like the best bet here (or
search the commons-user / dev archives for similar questions).
> addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
> addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
> }
>
> Any help or just some sample code how to modify would be a great help!
>
<snap/>
Once you get this bit going, that'd be quite a nice demonstration of
SCXML. If you're so inclined, I'd suggest thinking about contributing
back to the Commons SCXML community so the enhancements you've made
are available to the rest of us.
-Rahul
[1] http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials/RDCTemplate
[2] http://jakarta.apache.org/commons/sandbox/scxml/xref/index.html
[3] http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/SCXMLDigester.html#264
[4] http://jakarta.apache.org/commons/digester/
[5] http://wiki.apache.org/jakarta-commons/Digester
> Thanks,
>
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[SCXML] Help with SCXML Send usage
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
I appreciate your response. Yes, I did look at RDC and it does not meet
my needs. Your musicstore app required you to write two separate pages
(one for GUI, one for voice) although yes, you did get to reuse the
dialog and leverage your tags.
What I want is to have a single input (String) and output (XSL formatted
String) and a single file that defines our conversation. Essentially if
I deploy a client plug-in, it will transform whatever input received
into my single input and pass to my app, along with client type and
handle. My app will process the input based on conversation rules
defined in SCXML and ultimately return a formatted string using XSL for
that particular client.
I don't want to write JSPs for each, but rather have a single
input/output defined and write my app flow and logic using SCXML/VXML.
The SCXML spec:
http://www.w3.org/TR/2005/WD-scxml-20050705/#N104B9
This shows that you can declare a namespace and embed tags within the
Send element. Given vxml is structured for dialog, I hope to use it in
defining my "screens" using <form> and <menu> and letting XSL format it
for that particular client.
It's pretty simple, just need help getting the contents of Send. I am
paying a developer to help me so every hour is costing me... Ouch. Any
help you can provide, even a quick/dirty example of adding some rules
would be a great help.
If you could tell me what to add, I can have my "helper" add it for our
purpose. My guess is either modify line 264:
"/send"
to
"/send/form/block/prompt"
- I'm unfamiliar with how this works?
I assume then some modification to after line 579 in SCXMLDigester.java:
/**
* Add Digester rules for all actions ("executable"
elements).
*
* @param xp The Digester style XPath expression of the parent
* XML element
* @param scxmlRules The rule set to be used for digestion
*/
private static void addActionRules(final String xp,
final ExtendedBaseRules scxmlRules) {
addActionRulesTuple(xp + XP_ASN, scxmlRules, Assign.class);
addActionRulesTuple(xp + XP_VAR, scxmlRules, Var.class);
addActionRulesTuple(xp + XP_LOG, scxmlRules, Log.class);
addActionRulesTuple(xp + XP_SND, scxmlRules, Send.class);
addActionRulesTuple(xp + XP_CAN, scxmlRules, Cancel.class);
addActionRulesTuple(xp + XP_EXT, scxmlRules, Exit.class);
}
Any help or just some sample code how to modify would be a great help!
Thanks,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tuesday, December 06, 2005 12:02 AM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Help with SCXML Send usage
Hi Mike -
This is an interesting question, but before I attempt to answer -- I've
modified the email subject with a [SCXML] prefix, please try to add the
prefix when you start a thread, since some of us have email filters set
up.
On 12/5/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> We are trying to parse/use the content between <send> </send> tags and
> everything we try using the SCXML digester and Send methods retrieves
> null. We have successfully captured the <var> values, but nothing
> within <send> tags. Can you please provide information on how to
> retrieve this content using the code? Our SCXML test document is
> below:
>
> <?xml version="1.0"?>
> <scxml xmlns="http://www.w3.org/2005/07/SCXML"
> version="1.0"
> initialstate="logoff">
>
> <state id="logoff">
> <onentry>
> <var name="drink" expr="water" />
> <var name="eat" expr="flies" />
> <send target="http://localhost:8080/VXMLInterpreter"
> targettype="v3" xmlns:v3="http://www.w3.org/2005/07/vxml3"
> namelist="drink eat" event="" hints="" sendid="" delay="0">
> <v3:form id="Welcome">
> <v3:block><v3:prompt>Please enter your
> name.</v3:prompt></v3:block>
> </v3:form>
> </send>
> <log expr="'@@@@@@executed send@@@@@@@@'"/>
>
> <cancel sendId="send12345"/>
> </onentry>
>
> <transition event="go_login">
> <target next="login"/>
> </transition>
> </state>
>
> <state id="login">
> <transition event="go_logoff">
> <target next="logoff"/>
> </transition>
> </state>
>
> </scxml>
>
>
> Please help in allowing us to get the SCXML code to work. We've tried
> getExternalNodes() within Send and looked into the Rules for digester
> and do not know how to retrieve the <send>text</send> body elements.
>
<snip/>
Sorry, that digester rule is not in the current SCXMLDigester [1]. Let
me take this up as a TODO for myself, I'll try to get to this during the
upcoming weekend. I'll attempt to use NodeCreateRule [2] to prepare the
external nodes, but since we also need to process the known bits of the
SCXML <send> element, there'll be more than one digester rule involved.
This will allow the SCXML engine to react to external namespaces, as
long as the EventDispatcher [3] can locate a suitable namespace handler.
I believe SCXML has much promise when it comes to playing in Compound
Document Frameworks.
Having said that, a different approach is equally powerful, and
available immediately. I have written applications which do exactly what
you're alluding to above i.e. thinking of conversations as states and
transitions where each state has a corresponding activity which might be
a dialog of arbitrary complexity (one or more prompts and replies,
client side interaction or even multiple round trips to the server).
IIRC you've looked at the RDC framework [4], and it provides a SCXML
dialog management strategy for the group container [5]. A very simple,
fictitious use case example is here [6] for which the SCXML controller
is here [7]. Wrapping each activity in a RDC gives us:
a) A separation between the controller and the view
b) The interaction that needs to happen when you're in a particular
state can be fairly involved including any number of client server round
trips
c) You can make decisions about the transition you'd want to follow
based on prior interaction(s)
The separation in (a) is especially useful if you're authoring
multi-channel applications (voice, GUI, small device) since it
encourages reuse across different view layer markup. We have a multi
channel example [8] in the RDC distro which uses Struts wildcard
mappings and I've also demonstrated a proof of concept of how SCXML can
play in Struts Shale.
Please let me know if you have any other questions about SCXML, or how
it can be used to control a VoiceXML based conversation.
-Rahul
[1]
http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/sr
c/main/java/org/apache/commons/scxml/SCXMLDigester.java?view=markup
[2]
http://jakarta.apache.org/commons/digester/commons-digester-1.7/docs/api
/org/apache/commons/digester/NodeCreateRule.html
[3]
http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/sr
c/main/java/org/apache/commons/scxml/EventDispatcher.java?view=markup
[4] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
[5]
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorial
s/Aggregation
[6]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/scxml-dialog-test.jsp?view=markup
[7]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/config/scxml/scxml-test.xml?view=markup
[8]
http://svn.apache.org/viewcvs.cgi/jakarta/taglibs/proper/rdc/trunk/examp
les/web/musicstore-app/README?view=markup
---------------------------------------------------------------------
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