commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr -" <>
Subject [SCXML] SCXMLDigester setNamespaceAware
Date Fri, 16 Dec 2005 03:52:04 GMT
Hi Rahul,

Everything is working except one issue.  As we added
setNamespaceAware(true) in the digester, it adds some "junk" to our soap
message within the send tags.  For our specific purpose, it seems
unnecessary, but do you think making that setNamespaceAware(true) should
be configurable?  This way, for our use, we have strictly defined the
xml format to client/app so we don't need namespaces but others may.
For now, we'll just change that value to false but I propose that is
configurable value.



-----Original Message-----
From: Rahul Akolkar [] 
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List;
Subject: Re: [SCXML] Concurrent users

On 12/14/05, Mike Sparr - <> wrote:
> Hi Rahul,
> Two issues reported:
> EventDispatcher#send
> - inability to access context

Which is per design. Can you elaborate why the context should be

> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)

Yup, fixed in SVN :-)

> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we 
> would have to instantiate an SCXML obj (stateMachine) for each as well

> as executor?
> You mention "appropriately configured Executor" below.  I wonder if 
> you suggest each Executor instance also has its own unique state 
> machine (SCXML obj) instance too.

Yes, the SCXML object is the in-memory representation of an instance of
the state machine. The evaluation contexts hang off of each State within
the SCXML object, and so the reset method is clearing the contexts for
this instance of the state machine. For each new user/session, a new
instance is called for (SCXML as well as SCXMLExecutor).

>  If so, I'm curious what implications this
> would have on memory.

The SCXML Java object model is fairly lightweight. Since your usecase is
in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause for


> Regards,
> 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