commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SCXML-224) Improve SCXML state configuration handling and optional validation
Date Fri, 02 Jan 2015 19:30:35 GMT

     [ 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)

Mime
View raw message