commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] migration from old source to current - digest, exec, context handling
Date Mon, 19 Jun 2006 19:33:06 GMT
On 6/19/06, Mike Sparr - <> wrote:
> Hi Rahul,
> Everything seems to be working except for API Calls.  I changed line 455 of
> SCXMLDigester to setNamespaceAware(false) instead of true and it fixed my
> XSL transform issues.  Like we discussed, that was true by default but each
> implementation can decide what's best.

Yes, but you shouldn't have to change the library code ;-) I think the
last time we discussed this, we decided to leave the SCXMLDigester
configurable, i.e. you should be able to parse "manually" (using
digester API instead of the SCXML utility methods) if you don't want
the digester to be namespace aware, say like so:


import org.apache.commons.digester.Digester;
import org.apache.commons.scxml.PathResolver;
import org.xml.sax.ErrorHandler;


Digester scxmlDigester = SCXMLDigester.newInstance();
// or instantiate with a PathResolver, if document contains
// references to other documents

scxmlDigester.setErrorHandler(errorHandler); // always a good idea

SCXML scxml = null;
try {
    scxml = (SCXML) scxmlDigester.parse(scxmlDocumentURI);
} catch (Exception e) {
    // what makes sense here?

if (scxml != null) {

// use scxml object further as before


> The API Call issue is having problems with the Evaluator parsing the
> externalNodes content in our Dispatcher implementation?  Implementation:
>                        request.append(exec.getEvaluator().eval(
>                                exec.getRootContext(),
>                                MMIUtil.getBodyText(externalNodes)));
> I'm not sure as I checked the SCXMLExecutor and it still has the
> getRootContext() and getEvaluator() methods.  The getBodyText simply
> serializes the Nodes into a single string to pass as HTTP POST.
> ====
> Scxml source:
>                        <Request>
>                        <ItemId xsi:type="xsd:string">${cb.request}</ItemId>
>                        <ResponseGroup
> xsi:type="xsd:string">Small</ResponseGroup>
>                        </Request>
> The above is in the <send>SOAP ENVELOPE</send> where cb is a variable set
> earlier.  It has been evaluated several times to navigate to this event.
> Upon reaching our Dispatcher implementation, logs show the value (ISBN
> number) was passed but when the code above evaluated the externalNodes, it
> doesn't 'inject' the EL evaluated part??

Just to confirm, this is with an ELEvaluator? (clearly won't work with JEXL).

If so, I can't see why not, if the root context contains "cb".


> ====
> If you have any ideas why this could be I'd appreciate steer.
> Mike

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

View raw message