[
https://issues.apache.org/jira/browse/SCXML-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Wienke updated SCXML-205:
----------------------------------
Description:
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.
was:
In case of a statemachine that consists of only one state, the actions defined
on this state get called twice. The following scxml explains 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}
Both log messages appear 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.
> 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
> 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.2#6252)
