DO NOT MERGE: Add Microprofile Health

[Thihup]

IMPORTANT: Depends on Java 17, should be merged to 7.1.0, not earlier.

This change supports the deployment of MicroProfile Health 4.0 compatible applications, and modifies GF full profile to pass the MP Health 4.0.1 TCK by implementing the specification from scratch.

The MicroProfile Health uses the MicroProfile Config to check for two properties, so instead of requiring an explicit dependency,it handles the absence of the MP Config by returning a default value.

Currently this implementation does not add any default procedure.
Each application now contains four new endpoints: /health, /health/live, /health/ready and /health/started.

The TCK requires a single property (mp.health.disable-default-procedures) to be set (although currently unused by the implementation)

[arjantijms]

Wow, super cool! Just curious, how many of the TCK tests are passing at the moment?

Maybe the manifest.mf file can be generated? It usually is, but I didn't check yet if you're doing anything special. Just a quick glance.

[Thihup]

Tests passed/Failed/Skipped: | 27/1/0
The only test failing is the testEmptyReadinessWithConfig.

The main issue related to this failure is use of the Microprofile Config. As I'm creating a new MpConfigProviderResolver, it is not reading the microprofile-config.properties.

As I understand, the correct use should be ConfigProvider.getConfig(), but using it fails with No ConfigProviderResolver implementation found!. I couldn't understand why it was happening as I required the implementation (Import-Package: io.helidon.config.mp;).

Related to the manifest, I had to change it to allow the use of a higher CDI version. I followed the pattern of the microprofile-jwt-auth-api.

[Thihup]

Another issue: right now I'm registering the Servlet as the following http://localhost:8080/my-app/health, but the spec requires it to be http://localhost:8080/my-app/health.

[OndroMih]

@Thihup, regarding "As I understand, the correct use should be ConfigProvider.getConfig(), but using it fails with No ConfigProviderResolver implementation found!", this is probably related to classloading or the order in which MP Health and Config are initialized. Config in GF is initialized in https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/microprofile/config/src/main/java/org/glassfish/microprofile/config/ConfigDeployer.java. Maybe it happens after MP Health is initialized and thus Config is not yet available. If it's the case, we need to ensure that Health initializes after Config.

Alternatively, refactor ConfigDeployer.java to extract the initialization into a separate method that initializes MP Config if it's not initialized, and call the method directly from the MP Health initializer or via a CDI event triggered from the Health initializer. I prepared something like that in my local branch with experiments related to MP Config, which I only have locally and haven't prepared as a PR yet:

@Override
    public ApplicationContainer load(Container container, DeploymentContext deploymentContext) {
        initializeConfigProviders();
        return new ConfigApplicationContainer(deploymentContext);
    }

    /**
     * Initialise Config providers if they haven't been initialized
     */
    public void initializeConfigProviders() {
        if (!configProvidersInitialized) {
            final var resolver = new MpConfigProviderResolver();
            ConfigProviderResolver.setInstance(resolver);
            configProvidersInitialized = true;
        }
    }

And then ConfigDeployer could be injected into the Health initializer and call the initializeConfigProviders() method from there to ensure Config is initialized. Or, even better, fire an HK2 event from Health initializer and handle the event by calling the method.

[arjantijms]

Related to the manifest, I had to change it to allow the use of a higher CDI version. I followed the pattern of the microprofile-jwt-auth-api.

You are absolutely right. I missed it being in a patches folder.

(maybe for the future we can add some extension somewhere in OSGi so that we can more directly specify we allow higher versions, without patching the entire manifest)

[OndroMih]

The healthchecks are registered with "" context root but here we want to remove them by appInfo.getName(), which is not "". As a result, the health checks are not removed on undeployment, remain leaking, and even remain in the output of the /health endpoint.

[OndroMih]

This should bind the health checks to application name, which has to be unique. When undeployed, HealthService.event should unbind health checks for the same application name.

The problem with the current approach is that when 2 applications are deployed, they deploy all health checks under the same context name. When one of the applications is undeployed, it would remove health checks also from other applications. We need to add and remove health checks for a single application under a unique context.

[OndroMih]

From within an application. e.g. in the CDI extension, you can get the appname from InvocationManager.

There are multiple ways to retrieve it. The most straightforward is to get it from the global HK2 service locator via Globals.get(InvocationManager.class).

On InvocationManager, you get the app name:

InvocatoinManager im;
im.getCurrentInvocation().getAppName();

[OndroMih]

I tested it, all looks good!

I raised one PR with a fix for GlassFish: #25386. Without this, events are not properly triggered if app deployment fails, and then the healthchecks are not cleaned and leak until the app with the same name is deployed again and undeployed.

I raised a PR to this branch with an enhancement to add appname to the healthcheck report: Thihup#1