Rahul,

Context issue resolved but only way I could get app to work was to revert to
my handling SCXMLDigester.digest(URL, DefaultHandler).  As such, I had to
edit the library SCXMLDigester#digest#setNamespaceAware(false).  :(

I tried various combinations using Digester.parse but servlet always
returned blank screen with null printed.  Logs didn't show any errors so I
assume that scxml was not stored or executor not started.  I am going to
leave as-is for now.  At least I have latest library and will play with
DataModel and add tag library string parsing.

If you could overload the SCXMLDigester#digest(URL, ErrorHandler,
NamespaceAware) I'd be grateful.  :)  Perhaps it's best to modify the
newInstance() method and make that configurable instead of hard-coding
(true)??

I think the issue I'm facing is that ModelUpdater cannot be instantiated in
my Controller.  As such, I thing your SCXMLDigester can call it and that is
what starts the Executor and why I get 'null':

org.apache.commons.scxml.io.ModelUpdater is not public in
org.apache.commons.scxml.io; cannot be accessed from outside package
    [javac] import org.apache.commons.scxml.io.ModelUpdater;

I wrote exact same code in my Controller as you have in the #digest(URL,
Handler) and it failed as wouldn't compile when I referenced ModelUpdater
(above).  Not knowing what it really did, I commented it out to get build.
I ran app and just returned 'null'.  I reverted to calling digest method and
'hacking' library until fix (either make ModelUpdater public or preferably
update SCXMLDigester with new method).

Cheers,


Mike




On 6/20/06 10:35 PM, "Mike Sparr - www.goomzee.com" <[EMAIL PROTECTED]>
wrote:

> Hey Rahul,
> 
> To get the build working and change the namespace handling, I changed the
> reference to the filename as a String and used digester.parse(filename).
> Upon trying to run the application, I got error in browser stating that the
> build directory did not include the scxml source file???  (dir where I ran
> ant build).
> 
> I have engine xml doc in WEB-INF/classes/engine.xml  (in the classpath).
> Perhaps its best I put it elsewhere and should I reference a URI with that
> parse method?  (e.g. - http://localhost:8080/appname/engine.xml)?  Could you
> add a method to SCXMLDigester for setNamespaceAware so I can still use its
> #digest(java.net.URL) method?
> 
> In your tests, you have the SCXMLTestHelper class.  It digests the same way
> I used to (URL) which worked fine.  I don't think you have any tests that
> digest with setNamespaceAware(false) declared.  I propose adding that option
> to SCXMLDigester.
> 
>     public static SCXML digest(final URL url, final ErrorHandler errHandler,
>             final List customActions) {
>         Assert.assertNotNull(url);
>         // SAX ErrorHandler may be null
>         SCXML scxml = null;
>         try {
>             scxml = SCXMLDigester.digest(url, errHandler, customActions);
>         } catch (Exception e) {
>             Log log = LogFactory.getLog(SCXMLTestHelper.class);
>             log.error(e.getMessage(), e);
>             Assert.fail(e.getMessage());
>         }
>         Assert.assertNotNull(scxml);
>         return scxml;
>     }
> 
> As soon as I get this working, I can test that context change and report.
> 
> I think what I will have to do, is what you do in one of your
> SCXMLDigester#digest overloaded methods:
> 
>     public static SCXML digest(final URL scxmlURL,
>             final ErrorHandler errHandler, final List customActions)
>     throws IOException, SAXException, ModelException {
> 
>         SCXML scxml = null;
>         Digester scxmlDigester = SCXMLDigester
>                 .newInstance(null, new URLResolver(scxmlURL),
> customActions);
>         scxmlDigester.setErrorHandler(errHandler);
> 
>         try {
>             scxml = (SCXML) scxmlDigester.parse(scxmlURL.toString());
> 
> ...  I'll try that and stick with my java.net.URL and add PathResolver.  I'd
> rather add another overloaded method #digest(URL, ErrorHandler,
> CustomActions, NamespaceAware) if at all possible??? :)
> 
> Cheers,
> 
> 
> Mike
> 
> 
> 
> 
> On 6/20/06 12:23 AM, "Rahul Akolkar" <[EMAIL PROTECTED]> wrote:
> 
>> On 6/19/06, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote:
>> <snip/>
>>>  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.
>>> 
>> <snap/>
>> 
>> Mike -
>> 
>> Can you try the latest code in SVN (a clean checkout)?
>> 
>> While making some unrelated changes, I noticed one place where the
>> root context was being cleared a bit too aggressively.
>> 
>> -Rahul
>> 
>> 
>> 
>>> 
>>> Best,
>>> 
>>> Mike
>>> 
>> 
>> ---------------------------------------------------------------------
>> 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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to