Issue 703: making prevention of System.exit() calls configurable. #707
Conversation
This looks good. Thanks. Only when I tried an "ant release", the test process was abruptly terminated. It seems like the test case |
I have fixed the problem. All ant tasks should run now without errors |
Shouldn't the default be to prevent system exit? Since that's the old behaviour. |
well I am a fan of failing fast .. and clean coding:) And I have changed the behaviour only for test run as Junit-Tests , not from a fitnesse server. I can not see why we should tolerate/handle calling System.exit in Junit-Tests. If a developer makes such a thing then he should notice it soon and should fix it. If it is part of the test then it could be set for that test case. I don´t think it is critical if the test run is interrupted when a System.exit() is called in a junit test but it might be when the test is run from the UI of a central FitNesse instance. |
I'm also interested in this pull request as I am experiencing the same performance issue when running tests for i/o intensive applications. And I second benhamidene's optinion on preferring failing fast and better runtime performance in case of the junit-test runner instead of defaulting to the setting for the wiki-mode. |
Hi amolenaar, any chances to merge this commit ? not convinced by my answer :) ? |
:) I think you're right. The only doubt I have is that the default behaviours differ when executing a suite from the wiki vs. executing the suite from jUnit. |
I thought that I should provide some background information on why I initially introduced that feature. At a time there were lots of folks asking why FitNesse wasn't providing information on why a test was aborted. Most of these cases ended up as "production code called System.exit() for error handling". Eventually the amount of questions and people blaming FitNesse for the problems was so high, that we incorporated this feature. It seemed to be a good idea at that time. Now, be aware that changing the default behavior may have people coming back for the same reasons. Best Markus |
Hi ,
If you are not convinced and because the performance issue is very critical for us I could turn back the default behavior of the JUnitRunner and make a separate pull request for it that could be voted . |
I agree with your reasoning as far as point 1 and 2 go. Considering point 3, since we're executing tests in a separate process, it's harder to figure out what went wrong. It thing it would be fine if |
I understand the reasons why you changed the behavior. I also agree that System.exit() in applications is bad. Nevertheless people are doing terrible things out there, and I wanted to make you aware of the side-effects to your changes. I certainly agree with Arjan that the behavior should be consistent throughout the application no matter how you run it. Best Markus |
Introduced new property prevent.system.exit.
OK. You win :) I have updated the commit and added a short description for the property. Ant builds run without error. It should be ready to go now ;) Best regards . |
Issue 703: making prevention of System.exit() calls configurable.
Introduced new system property prevent.system.exit to control the activation of the SystemExitSecurityManager. Default behaviour is that the SystemExitSecurityManager is activated if the property is not found