Hi Rahul,
I was unaware that after you digest you could inject params (thought it was
static) hence my meddling with your source. I will definitely try the
mentioned approach as I like that much better - agreed that was what I was
shooting for during initial conversation.
Mike
On 6/19/06 1:33 PM, "Rahul Akolkar" <[EMAIL PROTECTED]> wrote:
> On 6/19/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> 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.
>>
> <snip/>
>
> 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:
>
> <code>
>
> <imports>
> import org.apache.commons.digester.Digester;
> import org.apache.commons.scxml.PathResolver;
> import org.apache.commons.scxml.io.SCXMLDigester;
> import org.apache.commons.scxml.io.ModelUpdater;
> import org.xml.sax.ErrorHandler;
> </imports>
>
> <fragment>
>
> Digester scxmlDigester = SCXMLDigester.newInstance();
> // or instantiate with a PathResolver, if document contains
> // references to other documents
>
> scxmlDigester.setNamespaceAware(false);
> 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) {
> ModelUpdater.updateSCXML(scxml);
> }
>
> // use scxml object further as before
> </fragment>
>
> </code>
>
>
>
>> 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??
>>
> <snap/>
>
> 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".
>
> -Rahul
>
>
>
>> ====
>>
>> If you have any ideas why this could be I'd appreciate steer.
>>
>>
>> Mike
>>
> <snip/>
>
> ---------------------------------------------------------------------
> 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]
