commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr - www.goomzee.com" <m...@goomzee.com>
Subject Re: [SCXML] migration from old source to current - digest, exec, context handling
Date Mon, 19 Jun 2006 20:24:57 GMT
:) Doh!  Nevermind.  I see you set the params BEFORE digestion.  That is
resolved and thankfully I don't have to branch the library.  :)

Regarding the EL issue, yes I stuck with EL instead of JEXL (reverted
rather).  I need to look at JSTL as you recommended to handle string
functions.  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.

I did notice that when updating /lib/ with the dependent jars a few things
broke so I reverted back to prior versions [digester, beanutils, logging,
el, etc.].  Just trying to get it stable again before plugging in new
functionality and staying as close to spec as possible (hence updating
library).

I'll keep digging - if I find out what it was I can let you know.  If
anything, early adopters can have a migration path to new version.  :)

Best,

Mike




On 6/19/06 2:01 PM, "Mike Sparr - www.goomzee.com" <mike@goomzee.com> wrote:

> 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" <rahul.akolkar@gmail.com> wrote:
> 
>> On 6/19/06, Mike Sparr - www.goomzee.com <mike@goomzee.com> 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: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message