commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr - www.goomzee.com" <m...@goomzee.com>
Subject Re: [SCXML] migration from old source to current - digest, exec, context handling
Date Wed, 21 Jun 2006 10:06:27 GMT
I tried 

<state id="something">

<datamodel>
<data name="foo"/>
</datamodel>

<transition event="something" cond="${Conversation.request == '1'}">
  <assign name="foo" expr="'bar'"/>
  <send ... Namelist="foo">
    <soap><env><body><operation>${foo}</operation></body></env></soap>
  </send>
</transition>

</state>

Both the <log> tag and <var> tags don't seem to be working.  <assign> and
<data> are not capturing any data at all.  Context is storing Conversation
obj which is accessible throughout.

I looked through all your tests and don't see any <doc-name>.xml that test
out the log or EL.  In addition, your SCXMLTestHelper seems to only support
JEXL.

Suggest test of datamodel, var, assign and send.  Not sure on what has
changed but temporarily will work with old codebase.  :(

/mike




On 6/21/06 2:35 AM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com> wrote:

> No luck.  EL or Context are not evaluating the variables within the
> transitions.  At the state level, they seem to be evaluated  <transition
> event="name" cond="${Conversation.request == '1324'}">
> 
> ...
> 
> </transition>
> 
> I see in your SCXMLExecutor#go method, which calls the #reset() method, it
> states something about only adding state-level variables to the context?
> See the implementation below that used to work fine with older library - now
> the navigation works fine until trying to evaluate <send> contents in
> Dispatcher...
> 
> ====
> 
> Mike
> 
> 
> On 6/21/06 1:07 AM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com> wrote:
> 
>> False alarm, still no expressions working - el not working in digester.:
>> 
>> Scxml code:
>> 
>> Another transition to capture FromZip triggers event to ToZip (below) and
>> then triggers getDistance.  Variables are passed in namelist (pre-datamodel
>> usage).
>> 
>>      <transition event="distance.toZip">
>>             <var name="cb" expr="${Conversation}" />
>>             <assign name="fromZip" expr="${cb.request}" />
>>             <send target="" targettype="client" event="distance.getDistance"
>> namelist="cb fromZip" delay="0" hints="" sendid="0009">
>> <vxml version="2.0">
>> <form>
>> <field name="input">
>> <prompt>To Zip Code?
>> </prompt>
>> <grammar src="builtin:grammar/digits?length5"></grammar>
>> <noinput><reprompt/></noinput><nomatch><reprompt/></nomatch>
>> </field>
>> <filled namelist="input">
>> <submit next="http://localhost:8080/appname/Voice" namelist="input"/>
>> </filled>
>> </form>
>> </vxml>
>>             </send>
>>          <target next="logged_in" />
>>      </transition>
>> 
>>      <transition event="distance.getDistance" >
>>             <var name="cb" expr="${Conversation}" />
>>             <var name="fromZip" expr="${fromZip}" />
>>             <var name="soapAction"
>> expr="http://www.tilisoft.com/ws/LocInfo/GetDistance" />
>>             <send target="http://www.tilisoft.com/ws/LocInfo/ZipCode.asmx"
>> targettype="api-soap" event="menu" namelist="cb soapAction" delay="0"
>> hints="" sendid="0001">
>> <SOAP-ENV:Envelope
>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>> <SOAP-ENV:Body>
>> <lit:GetDistance
>> xmlns:lit="http://www.tilisoft.com/ws/LocInfo/literalTypes">
>>   <!--Optional:-->
>>   <lit:ZipCode1>${fromZip}</lit:ZipCode1>
>>   <!--Optional:-->
>>   <lit:ZipCode2>${cb.request}</lit:ZipCode2>
>> </lit:GetDistance>
>> </SOAP-ENV:Body>
>> </SOAP-ENV:Envelope>
>>             </send>
>>          <target next="logged_in" />
>>      </transition>
>> 
>> 
>> 
>> ======
>> 
>> Log show message assembled (did not embed EL strings) ** note ZipCodes
>> didn't get injected into string ** :
>> 
>> <?xml version="1.0"?><SOAP-ENV:Envelope
>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><l
>> it:GetDistance 
>> xmlns:lit="http://www.tilisoft.com/ws/LocInfo/literalTypes"><lit:ZipCode1></
>> lit:ZipCode1><lit:ZipCode2></lit:ZipCode2></lit:GetDistance></SOAP-ENV:Body>
>> </SOAP-ENV:Envelope>
>> 
>> =======
>> 
>> Digester code:
>> 
>>                         request.append(exec.getEvaluator().eval(
>>                                 exec.getRootContext(),
>>                                 MMIUtil.getBodyText(externalNodes)));
>> 
>> ========
>> 
>> Adding a bunch of debug.outs to print out values of each to find out where
>> it's getting lost...
>> 
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>> 
>> On 6/20/06 11:36 PM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com>
>> wrote:
>> 
>>> Rahul,
>>> 
>>> Context issue resolved but only way I could get app to work was to revert to
>>> my handling SCXMLDigester.digest(URL, DefaultHandler).  As such, I had to
>>> edit the library SCXMLDigester#digest#setNamespaceAware(false).  :(
>>> 
>>> I tried various combinations using Digester.parse but servlet always
>>> returned blank screen with null printed.  Logs didn't show any errors so I
>>> assume that scxml was not stored or executor not started.  I am going to
>>> leave as-is for now.  At least I have latest library and will play with
>>> DataModel and add tag library string parsing.
>>> 
>>> If you could overload the SCXMLDigester#digest(URL, ErrorHandler,
>>> NamespaceAware) I'd be grateful.  :)  Perhaps it's best to modify the
>>> newInstance() method and make that configurable instead of hard-coding
>>> (true)??
>>> 
>>> I think the issue I'm facing is that ModelUpdater cannot be instantiated in
>>> my Controller.  As such, I thing your SCXMLDigester can call it and that is
>>> what starts the Executor and why I get 'null':
>>> 
>>> org.apache.commons.scxml.io.ModelUpdater is not public in
>>> org.apache.commons.scxml.io; cannot be accessed from outside package
>>>     [javac] import org.apache.commons.scxml.io.ModelUpdater;
>>> 
>>> I wrote exact same code in my Controller as you have in the #digest(URL,
>>> Handler) and it failed as wouldn't compile when I referenced ModelUpdater
>>> (above).  Not knowing what it really did, I commented it out to get build.
>>> I ran app and just returned 'null'.  I reverted to calling digest method and
>>> 'hacking' library until fix (either make ModelUpdater public or preferably
>>> update SCXMLDigester with new method).
>>> 
>>> Cheers,
>>> 
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> On 6/20/06 10:35 PM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com>
>>> wrote:
>>> 
>>>> Hey Rahul,
>>>> 
>>>> To get the build working and change the namespace handling, I changed the
>>>> reference to the filename as a String and used digester.parse(filename).
>>>> Upon trying to run the application, I got error in browser stating that the
>>>> build directory did not include the scxml source file???  (dir where I ran
>>>> ant build).
>>>> 
>>>> I have engine xml doc in WEB-INF/classes/engine.xml  (in the classpath).
>>>> Perhaps its best I put it elsewhere and should I reference a URI with that
>>>> parse method?  (e.g. - http://localhost:8080/appname/engine.xml)?  Could
>>>> you
>>>> add a method to SCXMLDigester for setNamespaceAware so I can still use its
>>>> #digest(java.net.URL) method?
>>>> 
>>>> In your tests, you have the SCXMLTestHelper class.  It digests the same way
>>>> I used to (URL) which worked fine.  I don't think you have any tests that
>>>> digest with setNamespaceAware(false) declared.  I propose adding that
>>>> option
>>>> to SCXMLDigester.
>>>> 
>>>>     public static SCXML digest(final URL url, final ErrorHandler
>>>> errHandler,
>>>>             final List customActions) {
>>>>         Assert.assertNotNull(url);
>>>>         // SAX ErrorHandler may be null
>>>>         SCXML scxml = null;
>>>>         try {
>>>>             scxml = SCXMLDigester.digest(url, errHandler, customActions);
>>>>         } catch (Exception e) {
>>>>             Log log = LogFactory.getLog(SCXMLTestHelper.class);
>>>>             log.error(e.getMessage(), e);
>>>>             Assert.fail(e.getMessage());
>>>>         }
>>>>         Assert.assertNotNull(scxml);
>>>>         return scxml;
>>>>     }
>>>> 
>>>> As soon as I get this working, I can test that context change and report.
>>>> 
>>>> I think what I will have to do, is what you do in one of your
>>>> SCXMLDigester#digest overloaded methods:
>>>> 
>>>>     public static SCXML digest(final URL scxmlURL,
>>>>             final ErrorHandler errHandler, final List customActions)
>>>>     throws IOException, SAXException, ModelException {
>>>> 
>>>>         SCXML scxml = null;
>>>>         Digester scxmlDigester = SCXMLDigester
>>>>                 .newInstance(null, new URLResolver(scxmlURL),
>>>> customActions);
>>>>         scxmlDigester.setErrorHandler(errHandler);
>>>> 
>>>>         try {
>>>>             scxml = (SCXML) scxmlDigester.parse(scxmlURL.toString());
>>>> 
>>>> ...  I'll try that and stick with my java.net.URL and add PathResolver.
>>>> I'd
>>>> rather add another overloaded method #digest(URL, ErrorHandler,
>>>> CustomActions, NamespaceAware) if at all possible??? :)
>>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>> Mike
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 6/20/06 12:23 AM, "Rahul Akolkar" <rahul.akolkar@gmail.com> wrote:
>>>> 
>>>>> On 6/19/06, Mike Sparr - www.goomzee.com <mike@goomzee.com> wrote:
>>>>> <snip/>
>>>>>>  Yes, the cb is in the context and EL works in controller but
>>>>>> after updating code, it doesn't evaluate in Dispatcher?
>>>>>> 
>>>>>> I didn't get that resolved but going to add some more debug.outs
to find
>>>>>> out
>>>>>> what's happening with the context.  As I stated before, the controller
>>>>>> places the executor in a store (bridge) after instantiation and the
cb in
>>>>>> context stores the handle (getClientIdentifier) so it can be retrieved.
>>>>>> Everything worked fine until update so there must be some minor change
>>>>>> I'm
>>>>>> not seeing.
>>>>>> 
>>>>> <snap/>
>>>>> 
>>>>> Mike -
>>>>> 
>>>>> Can you try the latest code in SVN (a clean checkout)?
>>>>> 
>>>>> While making some unrelated changes, I noticed one place where the
>>>>> root context was being cleared a bit too aggressively.
>>>>> 
>>>>> -Rahul
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> 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
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message