$Id$ COMMONS SCXML STATELESS_MODEL BRANCH -- PURPOSE -- To decouple the execution context for the Commons SCXML Java object model. -- STATUS -- This branch is CLOSED. The work done in this branch was merged with trunk in r375053. See Bugzilla issue 38311 for details. [ http://issues.apache.org/bugzilla/show_bug.cgi?id=38311 ] -- DETAILS -- A clean summary of the issue this branch attempts to work on was posted by Tim O'Brien to the commons-dev mailing list. 2. Decouple Execution Context from the SCXML Model Right now, the Context passed into the class that parses the XML and creates the SCXML object is the global execution context. You pass in a JexlContext when you are parsing the SCXML model, it is assigned to all of the State objects. So, bear with me, assume I have a SCXML document that represents the valid states of a stopwatch (ready, running, paused, stopped). The SCXML models the watch in a way similar to the microwave sample in the Working Draft, it uses a reference to a "timer" variable. To do this with the current implementation of SCXML, I would need to do the following twice (assuming a JexlContext): a. Create a JexlContext b. Populate the JexlContext with the appropriate variables c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want to execute this state machine with d. Create an instance of SCXMLExecutor, pass it the SCXML from step c. For each watch I need to model in this application, the implementation forces me to parse that SCXML document with Digester every time I want to model a separate StopWatch. In the application I'm interested in using this in, hundreds of documents in a content management system are going to be modeled as individual state machines, I would hate to have to parse an SCXML file for each individual document. * Alternative: Provide a mechanism that allows you to clone an SCXML instance so that you can create a separate SCXMLExecutor that can model the same statemachine with an isolated Context. * Better Alternative: States do not "have" a context. Take the context property off of the State and change executeActionList in SCXMLSemanticsImpl to get the Context from the Executor. Likewise, Transitions do not have a "notificationRegistry", take that property off of a transition and just have the SCXMLSemanticsImpl get the notificationRegistry from the Executor. I don't think this is a terribly difficult idea, and decoupling the description of the FSM from the execution state, would also make it much easier to persist either one. -- CHOSEN APPROACH -- We always go for the best approach around here, so we will go for the "Better Alternative" listed in the details section.