Ate Douma created SCXML-197:
-------------------------------
Summary: Provide a SCXMLEnvironment to encapsulate all
non-persitable and intermediate SCXML state and external Services for a
SCXMLExecutor
Key: SCXML-197
URL: https://issues.apache.org/jira/browse/SCXML-197
Project: Commons SCXML
Issue Type: New Feature
Affects Versions: 2.0
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.0
For the execution of a SCXML instance, several external services are used and
needed as well as intermediate state management and non-persistable objects as
well.
Currently these are spread out between the SCXMLExecutor and SCInstance (and
both marked as Serializable...) making it confusing and even incorrect how
these are managed.
The SCInstance keeps a map of current Invoker instances, while the semantics
for these Invokers are necessarily asynchronous and running in their own
thread. This makes them unqualified to be serialized together with the
SCInstance. I'll move these to the new SCXMLEnvironment instead.
SCInstance also holds the NotificationRegistry, which maintains a map of
external SCXMListeners, which likewise should not be serialized together with
the SCInstance. I will also move this NotificationRegistry to the
SCXMLEnvironment.
And the SCInstance hold a reference to the SCXMLExecutor, which is used for the
callback handling from Invokers, but if the SCInstance and/or SCXMLExecutor
would be serialized, there is nothing to 'talk back' to.
It will require some changes in the handling and communication with the
Invokers, but once done then the SCInstance also no longer need to reference
the SCXMLExecutor.
The SCXMLExecutor then, currently holds an EventDispatcher and ErrorReporter
which also are 'externally' provided. These 'services' also should move to the
new SCXMLEnvironment.
My intend is to make the SCXMLExecutor, and the new SCXMLEnvironment both
non-serializable and instead move the current Status and SCXML model object to
the SCInstance instance, which then properly and completely can encapsulate all
SCXML instance state, and be serialized (or persisted otherwise) if desired.
The SCXMLExecutor also currently holds the internal and external event queue
which I also will move to the SCXMLEnvironment.
The SCXMLEnvironment then will manage these event queues, and provide the SCMXL
I/O Processor services on top of them. This then also can be used to 'connect'
the Invokers instead of via the SCXMLExecutor like it is right now.
Finally, I will introduce a dedicated EnvironmentContext, also managed by the
SCXMLEnvironment, which will 'expose' the specification based environment
variables to the SCXML runtime (and ensure these variables are properly
readonly as required). This EnvironmentContext will be 'injected' between the
(external data) RootContext and the SCXML state contexts so they always will be
accessible from within the SCXML runtime.
The end result will be that the SCXMLExecutor only will need and have 3
(primary) instance variables: a SCXMLSemantics, SCInstance and SCXMLEnvironment.
The SCXMLExecutor role then properly and only will become a 'driver' for
executing an SCXML instance and also no longer needs to be serializable itself.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
