Remove system.exit from the health indicator and enhance the exception handler

[taban03]

Describe the bug The health indicator class contains system.exit, that shouldn't be used, in favour of unhealthy response

protected void doHealthCheck(Health.Builder builder) {

        boolean authUp = true;
        if (loginProviders.isZosfmUsed()) {
            try {
                authUp = loginProviders.isZosmfAvailableAndOnline();
            } catch (AuthenticationServiceException ex) {
                System.exit(-1);
            }
        }

        builder.status(toStatus(authUp))
            .withDetail(CoreService.AUTH.getServiceId(), toStatus(authUp).getCode());

    }

An API ML (ZWE*) message should rather be logged, with information about what actions the user should take:

i.e. Authentication service is not registered. Please verify the configuration and whether it is available The status response 503 indicating that the service is DOWN should also returned.

https://github.com/zowe/api-layer/wiki/Issue-management

[balhar-jakub]

The addition of the log message with the correct message ID seems to be the correct direction.

As for the removal of System.exit - The authentication service doesn't exist or isn't working and as such the API Mediation Layer wouldn't work, stopping it seems like a reasonable choice. Can we use other way to stop it?

[pablocarle]

The addition of the log message with the correct message ID seems to be the correct direction.

As for the removal of System.exit - The authentication service doesn't exist or isn't working and as such the API Mediation Layer wouldn't work, stopping it seems like a reasonable choice. Can we use other way to stop it?

I think the problem is that stopping it triggers a restart of the service by launcher. We've discussed this in the past, we should have a way to stop it without triggering a restart. In this particular case it may require a user action to fix connection with z/OSMF. I was thinking about the scenario with SAF provider, in this case the z/OSMF part of the condition will also not trigger.

[taban03]

And another possible scenario would be multi-tenancy where I think the central GW wouldn't require any authentication

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically closed due to lack of activity. If you disagree, please comment on reason why and reopen the issue