Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 20 Jun 2006 22:35:21 -0600
Subject: Re: [SCXML] migration from old source to current - digest, exec,
 context handling
From: "Mike Sparr - www.goomzee.com" <mike@goomzee.com>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Message-ID: <C0BE28A9.559A%mike@goomzee.com>
Thread-Topic: [SCXML] migration from old source to current - digest, exec,
 context handling
Thread-Index: AcaU7BrVWXqDMgDfEducUAAWy4loiw==
In-Reply-To: <ce1f2ea80606192323w24acfd37wd3ba8ed2ac891f0a@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

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" <rahul.akolkar@gmail.com> wrote:

> On 6/19/06, Mike Sparr - www.goomzee.com <mike@goomzee.com> 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: 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