commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr -" <>
Subject Re: [SCXML] migration from old source to current - digest, exec, context handling
Date Wed, 21 Jun 2006 05:36:29 GMT

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

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': is not public in; cannot be accessed from outside package
    [javac] import;

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



On 6/20/06 10:35 PM, "Mike Sparr -" <>

> 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( 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.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 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" <> wrote:
>> On 6/19/06, Mike Sparr - <> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message