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 08:35:37 GMT
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


Mime
View raw message