|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [jbehave-dev] [jira] (JBEHAVE-911) XML format is br... Yuriy Pilipenko (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Yuriy Pilipenko (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Ghislain Nadeau (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Ghislain Nadeau (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Ghislain Nadeau (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-911) XML format ... Mauro Talevi (JIRA)

Hi Ghislain,
I added your proposed fix for reporting the end of the scenario. Also, transformed your error-reproducing story into a unit test (see ConcurrencyBehaviour).
I do agree there is a potential race condition, but it's not possible/easy to fix in the current reporter architecture.
The best way forward is to deprecate the StoryReporter and replace it with a rendering of a performable tree model object, as done in 4.x branch. There the rendering is done after the execution based on the state of the tree.
Cheers