[jira] [Resolved] (SCXML-205) finalStep gets called twice

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SCXML-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved SCXML-205.
-----------------------------
    Resolution: Fixed

Thanks Johannes for catching and reporting this!

The SCXMLSemantics.finalStep() indeed is incorrectly invoked twice, and not just from SCXMLExecutor.reset() but also .eventStep().

As Woonsan already indicated, this is an regression since SCXML-197 where I moved the handling of the finalStep into the SCXMLSemantics.firstStep() and .nextStep() but forgot to remove them from SCXMLExecutor logic.

I've removed the old .finalStep() calls from SCXMLExecutor so it should now work again as expected.

> finalStep gets called twice
> ---------------------------
>
>                 Key: SCXML-205
>                 URL: https://issues.apache.org/jira/browse/SCXML-205
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Johannes Wienke
>            Assignee: Ate Douma
>            Priority: Critical
>
> In the current trunk version, finalStep and hence all onexit actions of the final state are called twice. The following scxml can be used to reproduce the problem.
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initial="Start" name="PublishEvent">
>   <final id="Start">
>     <onentry>
>       <log expr="'Entering state Start'"></log>
>     </onentry>
>     <onexit>
>       <log expr="'Leaving state Start'"></log>
>     </onexit>
>   </final>
> </scxml>
> {code}
> The onexit log message appears twice when running this example.
> I digged a bit in the source code and through a debugger I could find the cause for this effect: The finalStep method of SCXMLSemanticsImpl gets called twice. One backtrace looks like this:
> {noformat}
> SCXMLSemanticsImpl.finalStep(SCXMLExecutionContext) line: 215	
> SCXMLSemanticsImpl.firstStep(SCXMLExecutionContext) line: 132	
> SCXMLExecutor.reset() line: 331	
> SCXMLExecutor.go() line: 318	
> {noformat}
> and the seconds looks like this:
> {noformat}
> SCXMLSemanticsImpl.finalStep(SCXMLExecutionContext) line: 215	
> SCXMLExecutor.reset() line: 334	
> SCXMLExecutor.go() line: 318	
> {noformat}
> I am not sure about what should be the correct behavior, but to my mind, the second call looks suspicious.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)