commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] variable scoping
Date Sat, 08 Apr 2006 05:25:29 GMT
On 4/7/06, Mike Sparr - <> wrote:
> Hi Rahul,
> I have consolidated questions that have been looming below, plus response to
> your input on variable scoping.
> 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.

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.

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

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.

> 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?

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

> 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 and
> list all available functions with description/examples...

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

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.

> 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?

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?

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?


(long, possibly fragmented, URLs below)


> Mike

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

View raw message