On 4/7/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote: > Hi Rahul, > > I have consolidated questions that have been looming below, plus response to > your input on variable scoping. > > > WILL CHECK SYNTAX BASED ON SUGGESTIONS. > Tomorrow I will upgrade our snapshot with your changes. This message got > filtered as junk mail so I didn't see it until now. Thanks for the input. > Yes, based upon spec I should've been able to lazily instantiate the vars > w/o expr="" but will test that out with this snapshot. I did try the > <onentry><var...> and got exceptions but that could've been because I didn't > declare them as blank. I think I used expr="''" and other variations to get > it to work. > <snip/>
An empty expr attribute is no longer needed if you just want to define a variable with <var> (with a null associated value) -- fixed earlier in the week. The messages you are seeing in the logs are coming from the namelist in the <send> element, when the value of one or more variables in the namelist is null (one log message per variable) -- that is just to flag that a value of null was sent over the wire, which *might* be of interest for error reporting purposes. However, the error message is quite misleading, it says "UNDEFINED_VARIABLE" where it should really say something to the effect of "NULL_PARAMETER". If you want, you can file a report in bugzilla (details here [1]) for a better error message, so we don't forget this. > > SVN CHECKOUT? > The datamodel seems like best option so I'm looking forward to updating our > snapshot. Offhand, do you know the svn command/url to check out your > latest? First I'll test against your nightly binary tomorrow, but I have an > ANT build script for packaging everything so I want to pull down source. > <snap/> Sure, the Commons SCXML website [2] has all the information, including the SVN checkout URL and page on building Commons SCXML (see navigation bar on left). Building should be straightforward, since even with ant the dependencies are downloaded (which may not always be the most optimal approach, though its often easier). If you have trouble building, please ping the list. > > XMLNS ON/OFF IN DIGESTER? > In addition, I recall a while back that we modified your source to exclude > the xmlns handling in the digester - what was your final solution to that? > Did you turn it off, leave it on or make it configurable via the factory > suggestion? > <snip/> Yes, I remember that discussion. The outcome then was to allow digester instances configured for SCXML parsing to be available for further customization. Take a look at the SCXMLDigester class [3], specifically the newInstance() method. This page [4] from the user guide talks about customizing the Digester per individual needs, and though it talks about custom actions, the idea for any kind of customization is similar. The default SCXML digester is namespace aware. > > EL QUESTION (substring): > The voice browser being used (Nuance) had built-in grammars and leveraging > the currency grammar returns "USD20" for 20 dollars. In the EL I've tried > various attempts to parseInt or substring or replace to no avail. How would > I remove the currency code prefix using the EL in the framework? Do you > have a document on available functions - I've tried JSP 2.0 functions and > they didn't exist and documentation on Commons EL usage resorts to JavaDoc > but little/no function reference. Suggest Commons EL team copy PHP.net and > list all available functions with description/examples... > <snap/> Function invocation with JSP 2.0 EL (or why there was a lack thereof) has been a fun topic. JSP 2.0 EL does allow you to invoke "namespaced" functions, which are mapped to static Java methods. There are no "available functions". There is JSTL, which provides a functions tag library, and it does have the substringAfter() which is probably what you'd need here. The FunctionMapper in the Commons SCXML distro is not mapped to recognise that. It will indeed be useful, and for that, please open an enhancement request in bugzilla. The list of JSTL functions, BTW, is here [5]. <sidebar> While EL was the only expression language available in the early days of Commons SCXML, we can now use JEXL [6] as well. JEXL should be preferred since it allows method invocation and the ability to define custom functions would probably be easier given that JEXL 1.1 (not yet released) will support static method invocation. Migration from EL-based SCXML documents to JEXL-based SCXML documents, in many cases, is not much work. EL based documents make sense in servlet container based usecases, specifically those that may be tied to JSP/JSF technologies. Not sure if your usecase is so tied. </sidebar> > > SUGGESTION/QUESTION (toggle hot deploy/performance): > I think it would be beneficial to add in configurable hot-deploy/performance > modes. Hot-deploy would reload the engine document upon change and > performance would not. This likely would not be part of the commons > contrib. but do you know how I could implement that. The flexibility of > scripting new cases in the XML is enticing but continual server reboots to > clear memory hassle, especially for development. Suggestions? > <snip/> These are good points. If you're looking for hints, one possibility might be to look at how servlet containers "listen to" updates to web application descriptors (take Tomcat for instance, since we have the source ;-). If this can be done concisely, it can definitely be part of Commons SCXML, but its probably not on the 1.0 roadmap. If you have ideas about this (or even otherwise), you can open another enhancement request in bugzilla. Furthermore, in theory, it is also possible to programmatically alter the state machine's in memory representation (using the Commons SCXML object model), and this opens up the topic of enabling "adaptive behavior" -- and I find that quite interesting. To make that practical, some utilities will need to be added to Commons SCXML so its fairly straighforward for the user, such that most internal wirings for the object model are taken care of automagically. This should also be on the long term roadmap for Commons SCXML (another enhancement request, I might open this one myself instead of asking you to open all these ;-). > > SUGGESTION/QUESTION (performance/memory for executor store): > If app runs a long time, executor store may become rather large. Suggested > implementation? Currently Hashmap w/o worker for cleanup, ttl, timestamp. > Curious if best with timestap, ttl and perhaps LRU LinkedList > implementation? > <snap/> We now use a stateless model for Commons SCXML, see issue 38311 [7] for the details. This means the document needs to be parsed only once (only one SCXML object is created), and the SCXMLExecutor's should be made candidates for being collected when you're done with them (in the worst case, they'll be lost as each session terminates/expires). So am not sure if anything beyond that is needed. Are you having any memory issues when using the latest nightlies? -Rahul (long, possibly fragmented, URLs below) [1] http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html [2] http://jakarta.apache.org/commons/sandbox/scxml/ [3] http://jakarta.apache.org/commons/sandbox/scxml/apidocs/org/apache/commons/scxml/io/SCXMLDigester.html [4] http://jakarta.apache.org/commons/sandbox/scxml/guide/custom-actions.html [5] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/fn/tld-summary.html [6] http://jakarta.apache.org/commons/jexl/ [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=38311 > > Mike > > <snip/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
