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 04:35:21 GMT
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) {
        // 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);
        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),

        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??? :)



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:

View raw message