commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr -" <>
Subject RE: [SCXML] SCXMLDigester setNamespaceAware
Date Fri, 16 Dec 2005 23:04:28 GMT

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" >
            <i1 xsi:type="xsd:int">${cb.request}</i1>
            <i2 xsi:type="xsd:int">${cb.request}</i2>
         <target next="state_login" />

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">
            What do you want to do? <enumerate/>
             1. Chat
             2. Logoff    
      </send >
    <target next="state_welcome" />

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.



P.S. - where do you work? And are you in US?

-----Original Message-----
From: Rahul Akolkar [] 
Sent: Friday, December 16, 2005 12:55 PM
To: Jakarta Commons Users List;
Subject: Re: [SCXML] SCXMLDigester setNamespaceAware

On 12/15/05, Mike Sparr - <> 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.

"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.

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).


> Cheers,
> Mike

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message