[
https://issues.apache.org/jira/browse/SCXML-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated SCXML-224:
----------------------------
Description:
The (new) SCXML state configuration handling isn't properly handling
intermediate (in-progess) transitions yet as it currently only
updates/refreshes the state configuration (through the Status object) after
processing a step.
This causes errors like reported on SCXML-208 but also [SCXML
IRP|http://www.w3.org/Voice/2013/scxml-irp/] test failures (tests 409, 411 and
417).
As the Status object is directly mutable *and* dynamically derives the active
states, this needs a new/immutable implementation without (need for) caching
the active states.
To keep supporting setting the current state configuration a new API will be
added to the SCXMLExecutor to (only) set the state configuration through atomic
stateIds, which also first will check the resulting configuration is a
valid/legal configuration.
Finally, as checking the legal configuration in itself can be relatively
time-consuming and this not always might be needed (if the state machine is
properly defined and controlled), checking the configuration will be made
optional (default enabled).
These changes will have some API changes as result but should be trivial to be
resolved at compile time.
was:
The (new) SCXML state configuration handling isn't properly handling
intermediate (in-progess) transitions yet as it currently only
updates/refreshes the state configuration (through the Status object) after
processing a step.
This causes errors like reported on SCXML-208 but also SCXML IPR test failures
(tests 409, 411 and 417).
As the Status object is directly mutable *and* dynamically derives the active
states, this needs a new/immutable implementation without (need for) caching
the active states.
To keep supporting setting the current state configuration a new API will be
added to the SCXMLExecutor to (only) set the state configuration through atomic
stateIds, which also first will check the resulting configuration is a
valid/legal configuration.
Finally, as checking the legal configuration in itself can be relatively
time-consuming and this not always might be needed (if the state machine is
properly defined and controlled), checking the configuration will be made
optional (default enabled).
These changes will have some API changes as result but should be trivial to be
resolved at compile time.
> Improve SCXML state configuration handling and optional validation
> -------------------------------------------------------------------
>
> Key: SCXML-224
> URL: https://issues.apache.org/jira/browse/SCXML-224
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> The (new) SCXML state configuration handling isn't properly handling
> intermediate (in-progess) transitions yet as it currently only
> updates/refreshes the state configuration (through the Status object) after
> processing a step.
> This causes errors like reported on SCXML-208 but also [SCXML
> IRP|http://www.w3.org/Voice/2013/scxml-irp/] test failures (tests 409, 411
> and 417).
> As the Status object is directly mutable *and* dynamically derives the active
> states, this needs a new/immutable implementation without (need for) caching
> the active states.
> To keep supporting setting the current state configuration a new API will be
> added to the SCXMLExecutor to (only) set the state configuration through
> atomic stateIds, which also first will check the resulting configuration is a
> valid/legal configuration.
> Finally, as checking the legal configuration in itself can be relatively
> time-consuming and this not always might be needed (if the state machine is
> properly defined and controlled), checking the configuration will be made
> optional (default enabled).
> These changes will have some API changes as result but should be trivial to
> be resolved at compile time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
