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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> wrote: >> >>> On 6/19/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]