Reduce using `System.exit`
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 92
- Forks
- 81
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 46
Description
Describe the bug
The code of APIML contains about 10 calls of System.exit. It is not a best practice and can lead to issues (ie. https://github.com/zowe/api-layer/pull/2923#discussion_r1212887630).
The code should be replaced at least with SpringApplication.exit (https://www.baeldung.com/spring-boot-shutdown#exit)
Also when apiml starts the SpringApplication.exit didn't work well. The service itself is shutted down but some threads are still alive (Eureka and maybe others). From this reason a hotfix was added (https://github.com/zowe/api-layer/pull/4457/files#diff-ed3a10b0979a105727e2c0736d8bcd8e962920a11e2b7827ff10f249965d9b1dR56). This issue should solve also this one.
Expected behavior
Code does not contains any directly call of System.exit
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the roughly ten System.exit calls in the APIML code and review the SpringApplication.exit approach plus the hotfix linked in the issue. Replace direct calls while preserving shutdown behavior, including Eureka and other lingering threads; done means no direct System.exit calls remain and services terminate cleanly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring-boot
- Domain
- api, backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100